这种不能简单通过谁方便、请求多少来考量。举个例子。

复杂详情页面。比如，商品的详情页面。

详情页面大概会有如下内容：
a. 商品自身的信息；
b. 优惠 & 活动；
c. 评论（列表）；
d. 相关推荐（列表）。

这时候后端是只给你一个接口好，还是分多个接口去请求好？

从用户的体验来讲，最好先快速加载并渲染出商品信息、优惠信息。其次才是热评、最后是相关推荐。

我个人认为，这种场景真的只用一个接口的话。体验大概率会比较差。分成多个接口，各自加载、渲染可能会更好。那些评论、相关推荐的数据大概率没有商品自己的信息加载来得快。

需求太多变的场景下，73# 的说法挺适用的。

别别别，业务代码真别用复杂体操。

TypeScript 你区分清楚哪些是 type ，哪些是 js 的代码就很阿弥佗佛了！日常用起来基本不会有什么问题。最低标准是一个逻辑单元对外的要有类型，对内实在没办法的地方就用 any 与 as 。没必要追求处处都要类型自洽。

进阶一点，知道 narrowing 、一些类型自动推导的逻辑即可。

类型体操，即便是写 lib 也不是太推荐用复杂的类型体操。太多次的变换、跳转，让用 lib 的人查起来也是很费力。

我感觉 Google 这种企业的做法合理一点，stack overflow 三天两头弹同意 cookie 的弹窗真的很烦。

1. 技术上并不是需要用户同意。实际上你爱怎么用，就怎么用。但是欧盟有法律限制，具体不是很清楚，貌似是第三方 cookies 的使用需要用户同意。因为这些第三方 cookie 基本是 google ads 之流，轻松可以追踪到用户的浏览行为。你自己网站需要用的必要 cookies 不受此限制。虽然只是欧盟有这些限制，但是不知道为什么很多网站都把这种要“用户同意使用 cookie” 的弹框对所有地区的访客开启。我曾经试过访问一些国际大企业的网站，比如 Google 搜索，当你把代理设置在欧盟国家的时候，会弹出一个条款要你同意，但是代理设置成欧盟外的地区，这个弹框又不会出现。

2. 回到技术层面，你这种方案有一定风险。cookies 只是存储介质，如果只是存储一些 session 统计等无关紧要的信息，那你这样做也所谓。但是当 cookie 存储的信息是身份验证信息的时候，你的这种处理方式会带来一定风险。js 能把 cookie 丢到 localStorage ，意味着你的这种 cookie 可以被 JS 读取，意味着如果网站有 XSS 漏洞，用户的 身份验证信息会被攻击者偷走。一般而言，用来存储身份验证信息的 cookie 不需要用户同意。一般要设置成 Http-Only （ JS 无法读取，也就不会被 XSS 攻击者窃取）、Secure （只能在 https 这类安全通讯协议上传输）、SameSite 至少设置为 Lax （老版本的浏览器并没把 Lax 设为 SameSite 的默认值）。

有时候真的觉得这些不重要。以前喜欢折腾 emacs 、vim ，那时候要是有 vscode ，估计也会折腾 vscode 。工作几年后，基本只用 JetBrain 系列的东西。环境这种东西，开箱即用是最好的，或者积累足够一定的痛点后，再去想着优化即可。

还是以前的一位同事说得在理，软件开发的瓶颈在思维又不在编码上。思路错了，你写得再快又如何？

@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 保护，是为了 **向后兼容**。