同源策略机制、与CORS的区别及简单POST免预检原因问询

一、同源策略（SOP）的实际机制 #

同源策略是浏览器内置的安全机制，核心目的是防止恶意页面通过JS窃取其他网站的敏感数据。它的判断规则很明确：两个页面的协议、域名、端口三者完全一致，才算“同源”。

它的实际限制逻辑：

• 对于JS发起的请求（比如AJAX、fetch），如果跨域，浏览器会在收到服务器响应后拦截响应内容，不让JS读取；但请求本身是会发送到服务器的（pre-CORS时期）。
• 对于<img>、<script>、<link>这类标签发起的资源加载请求，SOP不限制加载行为（因为这些资源是被动渲染/执行，JS无法直接读取原始响应内容），这也是CDN资源能跨域使用的基础。

二、SOP与CORS的核心区别 #

• SOP是默认的限制规则：浏览器天生就会执行SOP，默认禁止JS读取跨域响应，不需要服务器做任何配置。
• CORS是SOP的扩展授权机制：它是为了解决合法跨域需求而出现的，通过服务器返回特定响应头（比如Access-Control-Allow-Origin），告诉浏览器“这个跨域请求是被允许的，可以让JS读取响应”。本质是服务器主动开放跨域访问权限，浏览器根据服务器的授权决定是否放行响应。

三、为什么简单POST请求无需预检？ #

预检请求（OPTIONS方法）的作用是：在发送可能修改服务器状态的跨域请求前，先询问服务器“是否允许这个请求”，避免服务器执行了状态变更操作，却因为跨域被浏览器拦截响应，导致前端和服务器状态不一致的问题。

而简单POST请求不需要预检，核心原因是兼容性：在CORS出现之前，表单提交的跨域POST本来就是合法的（比如你可以在A网站的表单提交到B网站，只是提交后页面会跳转到B，JS拿不到响应）。这类请求已经被服务器广泛支持和处理，CORS为了兼容这种旧有场景，将符合以下条件的POST归为“简单请求”，跳过预检：

• 请求方法为POST
• Content-Type只能是application/x-www-form-urlencoded、multipart/form-data或text/plain
• 没有自定义的HTTP请求头

简单来说，这类请求在pre-CORS时期就已经能正常发送，服务器不会因为CORS的出现突然无法处理，所以不需要额外的预检步骤。

四、纠正你的误解 #

1. pre-CORS时期没有预检和CORS响应头：预检请求（OPTIONS）和Access-Control-*系列响应头都是CORS规范引入的，SOP本身没有这些机制。在CORS出现前，浏览器只会拦截跨域响应，不会先发OPTIONS询问。
2. 简单跨域请求的逻辑你后半部分是对的：pre-CORS时期，浏览器会发送简单跨域请求（比如符合上述条件的POST），服务器会接收并处理（状态确实会被修改），但浏览器会拦截响应，JS无法读取内容。这也是为什么早年跨域表单提交可行，但AJAX跨域拿不到数据的原因——SOP限制的是响应的读取，不是请求的发送。

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