@bthulu {哭笑脸} “打日志警告人工处理”，项目初期很受用。

个人还是不太看好纯社区驱动的东西。

忘记以前看的哪本书，貌似是讲 CSS 的，那个作者说，要伺候一群来自不同公司的 web 委员会成员，就像要伺候十几种猫一样，太难伺候了。


有社区、有一定的开放性，然后再有一个强大的企业来引导，个人感觉是比较好的。

@Zhuzhuchenyan 好，感谢～

右边的 Ctrl 、Alt 、Command 一般很少很少用到，所以可以自己用来改成一些快捷键的映射。这样大部分情况下不影响键盘的本来面貌，又可以扩展一些快捷键。我个人只用两个改键方案：

1. 右 Alt + p/n/b/f 映射成 剪头上下左右，接近 Emacs 的移动光标方案；
2. 右 Command 映射成 Ctrl + Alt + Command + Shift 。这样可以很方便的触发很特殊的四个修饰键的快捷键方案。配合一些快捷键注册服务使用。比如，右边 Cmd + T 就是切换到终端，+ C 就是切换到 Chrome ，+ P 就是切换到 PyCharm 。

@zy445566
@tool2dx

先前实验下来的确有这个发现。浏览器对于当前 document 访问，是会忽略缓存相关的 Header 。即便我问的这个 `immutable` 也是会忽略的。

iframe 确实没实验过。感谢分享！

@sagaxu 你说的那是协商缓存吧？ Expires 与 Cache-Control max-age=XXX 是强缓存。

@bxb100 感谢～ 这个 Q&A 说得很清楚。

@lovelylain 浏览器为了向后兼容，依然允许表单构建的请求进行跨域。而表单请求只有 GET/POST 两种 method 。这种请求，是有办法自动带上目标网站的 Cookie 的，从而实现 CSRF 攻击。

我认为是可以的。如果请求允许 PUT ，那么就无法在浏览器端构建出 CSRF 攻击。

但是，这种防御方式有点自损八百的感觉。

另外，我心中也有一个疑惑，为什么有的人要把 CSRF token 存放到 session 里？我感觉这种绑定的意义不大，还增加服务的负担。

不用讨论这样做 CORS 。我只是读文档，有疑惑而已。

楼上 #1, #6 说的是正解，非常感谢~ 意思就是说，简单请求 **只是** 不触发预检，并不是说这类请求能绕过 CORS 保护。

而 script 、img 、link 、form 这类标签构造出来的请求能绕过 CORS 保护，是为了 **向后兼容**。

太正常了。

web 环境跟 server 环境经常混为一谈。狭义一点的 web 环境，应该是指浏览器环境。 但是 http server 不是只服务于浏览器。

经典的几个莫名其妙的问题以及神奇操作。

1. cookie 与 session 有什么区别？二者不是之间替代品，没什么好比较。
2. cookie 与 jwt token 有什么区别？二者不是之间替代品，没什么好比较。
3. 在浏览器环境，把 jwt token 塞 Authentication header 里。那请问你的 jwt token 不是需要让 js 访问吗？那不是等于会泄露在某处？
4. 把公开的 API 加上 CSRF 保护。这类 API ，一般会用服务于 sdk 、app 、server 2 server ，这种场景下防什么 CSRF 攻击。CSRF 攻击只在浏览器发生。server 可以分流，身份信息 放在 cookie 里的，是浏览器流量，需要 CSRF 保护，放在 Authentication header 里的，是一些非浏览器流量，不需要 CSRF 保护。
...

GraphQL 之前的项目用过。现在接一些第三方服务也会用到。反正还是喜欢不起来，感觉国外比较受欢迎。

我不喜欢大概有两点：
1. 引入新的 DSL 。我觉得 API 对接还没到需要引入一个 DSL 的地步，围绕着这个 DSL 有好多生态要搭建，做不好体验就比较差。写 query 时的字段补全、嵌套 format 等等问题。感觉体验不太好。
2. 容易写成一个臃肿的请求。

没有细看过 trpc ，它跟 grpc 比起来有什么优势吗？ grpc 也能生成 TS client ，不过感觉确实有类型丢失。

感谢 感谢～ 感觉拓宽了视野，也清晰了很多。

回到这个 “业务异常” 上来。我在 rpc 服务供应端实现的时候，是不是可以通过抛出异常然后在出口统一拦截这类业务异常转成正常数据交换的实现方式？当然，这类所谓的“业务异常”并不是程序错误，就不需要上报监控了，不混入其它的错误监控中去。

@povsister

我可不可以这样理解：

1. 对于我描述的这类异常，应该属于 “业务异常”。说是异常，其实是正常的数据交互。类似的还有，邮箱已被使用、账号或密码不存在等。这些不属于程序错误，监控也不需要关心这些业务异常。

2. 还存在一类异常，为了区分称为“程序错误”吧。这些是程序员真正需要关心的，需要有你说的描述、场景、debug 信息。我能想到的典型，可能是 “配置不存在”、验证 Token 解析失败这类错误。总之是不符合预期的、需要监控关心的问题。

话说，才发现 coding 节点算是 CodingNet 的营销节点。。。