为什么POST请求不会触发CORS跨域预检检查？

核心原因本质是两个：CORS的设计目标本就不包含防御CSRF，同时需要兼容Web诞生以来就存在的跨域表单提交历史逻辑，具体拆解如下：

• 首先要纠正一个普遍认知误区：CORS从来不是一套跨域安全防御机制，它的核心作用是「在保留原有Web安全模型的基础上，给服务端开放跨域资源共享的配置能力」。它管控的边界从来都是跨域请求的响应是否允许被前端JavaScript读取，而非跨域请求是否允许被发送。CORS规范的所有默认规则，都严格对齐了CORS出现之前浏览器的默认跨域行为——所有以前浏览器就能发出去的跨域请求，在CORS体系下都属于不需要预检的“简单请求”，不会因为CORS的存在新增任何新的攻击面。你提到的跨域POST携带Cookie触发发信操作的CSRF场景，早在CORS规范诞生前就已经存在——早年通过<form action="https://email.com/send" method="POST">标签，不需要任何JS就能完成完全一样的攻击，这和CORS规则没有任何关系。
• 其次是无法承担的兼容性代价。不需要预检的POST请求是被严格限定在「传统HTML表单原生支持的能力范围」内的：仅允许application/x-www-form-urlencoded、multipart/form-data、text/plain三种Content-Type，不允许携带自定义请求头。这套跨域提交表单的逻辑从Web 1.0时代就已经是标准行为，大量现存业务（比如跨域支付回调、公开的表单投递接口、第三方系统的简单数据上报）都依赖这个逻辑运行。如果强制所有POST请求都先发送预检OPTIONS请求，等于直接打破互联网运行了二十多年的默认规则，海量老站点会直接失效，这个兼容性成本是W3C在制定规范时完全不可能接受的。
• 反过来想，如果真的把所有POST都纳入预检范围，会带来毫无必要的性能损耗：每一次POST请求都要额外多发送一次OPTIONS预检请求，整体网络开销翻倍，服务端也要额外处理大量无意义的OPTIONS请求，投入产出比极低。
• 最后，你提到的CSRF风险本来就有对应成熟的防御方案：比如校验请求的Origin/Referer来源、设置Cookie的SameSite属性、携带仅前端页面能获取的CSRF Token做二次校验，这些都是服务端做写操作身份校验时本该落地的逻辑，本来就不该由跨域资源读取规则来兜底。

补充说明：只要你的POST请求超出了传统表单的能力范围，比如使用application/json编码、添加自定义鉴权请求头，现有CORS规则本来就会自动触发预检流程，不存在漏过的情况。

内容的提问来源于stack exchange，提问作者Daavee18