JavaScript中Fetch的mode：no-cors、cors与same-origin的区别
2026-5-27
搞懂同源策略、CORS 和 no-cors：全面对比
嘿，我来帮你把这三个容易混淆的概念彻底捋明白——刚接触跨域的时候，我也差点把它们搞混，咱们一步步拆解：
1. 先搞懂最基础的：Same-Origin（同源策略）
说白了，同源策略是浏览器的核心安全防线，它规定：只有当两个页面的「协议、域名、端口」三者完全一致时，才算是“同源”，此时页面之间才能自由共享数据（比如Cookie、LocalStorage、DOM元素）。
举几个例子：
https://example.com和https://example.com/page1→ 同源（路径不同不影响）https://example.com和http://example.com→ 不同源（协议：https vs http）https://example.com和https://sub.example.com→ 不同源（域名：主域 vs 子域）https://example.com和https://example.com:8080→ 不同源（端口：默认443 vs 8080）
它的作用是啥？比如你登录了网银，又不小心打开了一个恶意网站，同源策略会直接阻止恶意网站读取网银页面的Cookie，避免你的账户被盗。
2. CORS：合法突破同源策略的“通行证”
CORS（Cross-Origin Resource Sharing）是浏览器和服务器之间达成的一套跨域通信规则，用来在安全前提下允许跨域请求获取数据。
当你的前端页面（比如https://my-frontend.com）要请求另一个域名的接口（比如https://my-api.com/data）时：
- 浏览器会先发送一个
OPTIONS预检请求（复杂请求才会发，简单请求直接发），询问服务器“这个跨域请求你允许吗？” - 服务器返回响应头，比如
Access-Control-Allow-Origin: https://my-frontend.com（或者*允许所有域名），同时可以搭配Access-Control-Allow-Methods、Access-Control-Allow-Headers等字段，明确允许的请求方法和头信息。 - 浏览器看到服务器的允许指令后，就会放行后续的请求，并且让前端可以正常读取响应的数据。
简单说：CORS是让跨域请求能拿到数据的合法方式，前提是服务器必须配置对应的响应头。
3. no-cors：跨域请求但“拿不到数据”的静默模式
这是fetch API里的一个请求模式选项（mode: 'no-cors'），它的特点是：
- 允许发起跨域请求，但浏览器会严格限制请求的范围：只能用HEAD、GET、POST方法，请求头只能是“简单头”（比如Accept、Content-Type: application/x-www-form-urlencoded等）。
- 最重要的：你完全无法读取响应内容——浏览器会把响应标记为“opaque（不透明）”，前端只能知道请求成功了，但拿不到响应体、响应头这些数据。
什么时候用？比如你要加载一个第三方的图片、字体或者脚本，不需要读取它们的内容，只是让浏览器把资源加载进来就行。这时候用no-cors可以避免跨域报错，但别指望能拿到数据。
三者全面对比表
| 维度 | Same-Origin（同源策略） | CORS | no-cors |
|---|---|---|---|
| 核心目的 | 限制跨域数据访问，保障安全 | 合法允许跨域并获取数据 | 允许跨域请求但不获取数据 |
| 是否允许跨域请求 | 仅允许同源请求 | 允许符合规则的跨域请求 | 允许有限的跨域请求 |
| 能否读取响应内容 | 可以自由读取 | 可以读取（服务器允许） | 完全无法读取响应内容 |
| 请求限制 | 无限制（同源内） | 支持所有HTTP方法/头（需服务器配置） | 仅支持HEAD/GET/POST，仅允许简单头 |
| 服务器是否需要配置 | 无需配置 | 必须配置CORS响应头 | 无需服务器配置 |
| 典型适用场景 | 同源页面间的数据共享 | 前端跨域请求API接口 | 加载第三方静态资源（图片、字体等） |
总结一下：同源策略是安全基础，CORS是跨域拿数据的正规途径，no-cors是跨域请求但“只读不存”的特殊模式——根据你的实际需求选对应的方式就好。
内容的提问来源于stack exchange，提问作者Meroz
相关产品推荐
相关产品推荐
