CORS与NO-CORS区别解析

CORS与NO-CORS并非简单的“允许或禁止跨域”，而是浏览器对跨域通信中「请求能否发出」和「响应能否被脚本读取」的双重独立控制机制：`mode: 'cors'` 在服务端正确配置CORS响应头（如Access-Control-Allow-Origin）的前提下，支持完整读取响应数据、状态码和头部，适用于需获取API返回、下载文件等场景；而`mode: 'no-cors'`则主动放弃响应访问权，仅保证请求能发出，响应始终为opaque（不可读、无状态、无内容），专为埋点上报、Webhook触发等单向通信设计——选错模式不仅无法绕过限制，反而会因能力误判导致数据丢失或调试失效，真正可靠的跨域方案永远建立在前后端协同配置或后端代理的基础之上。

理解 mode: 'cors' 和 mode: 'no-cors' 的区别，关键在于看清浏览器对「请求能否发出去」和「响应能否被脚本读取」这两件事的分开控制。它们不是简单的“开/关跨域”，而是定义了不同安全等级下的行为契约。

mode: 'cors' —— 可读响应的跨域请求

这是 fetch 跨域请求的默认模式（显式写或不写效果一致），目标是让前端既能发送跨域请求，又能安全地读取响应内容。但前提是服务器必须配合：

• 浏览器会根据请求特征决定是否先发 OPTIONS 预检（比如带 Content-Type: application/json 或自定义 header 就会触发）；
• 服务器必须在响应头中返回 Access-Control-Allow-Origin，且值匹配当前源（如 https://localhost:3000）；
• 若需携带 Cookie 或认证信息，还需额外设置 credentials: 'include'，且服务端要返回 Access-Control-Allow-Credentials: true；
• 只有满足这些条件，response.json()、response.blob() 才能正常拿到数据，状态码和 headers 也可访问。

mode: 'no-cors' —— 只发不读的“哑请求”

这个模式不是为“绕过跨域”，而是为兼容某些历史场景（如图片、脚本加载）。它放弃对响应的控制权，换来的是“一定发得出去”：

• 只允许 GET、HEAD、POST 方法，且 Content-Type 仅限 text/plain、application/x-www-form-urlencoded、multipart/form-data；
• 所有非简单请求头（如 Authorization、Content-Type: application/json）会被浏览器直接忽略；
• 响应始终是 opaque：无法读取 status、headers、body，response.blob() 返回空 Blob，下载文件就是 0 字节；
• 它不解决跨域问题，只是把跨域请求降级为“单向通信”——适合埋点上报、Webhook 触发等无需响应内容的场景。

为什么不能混用？常见误操作解析

很多问题源于对两个模式能力边界的混淆：

• 在 no-cors 下加 Access-Control-Allow-Origin 请求头：这个头是服务器返回给浏览器的，前端加了无效，还可能引发预检失败；
• 用 no-cors 下载文件却期望得到完整二进制：响应不透明，blob 必为空，必须切回 cors 模式并确保服务端正确配置 CORS 头；
• 删掉 Content-Type: application/json 就以为能避免预检：确实可变简单请求，但如果服务端仍不返回 Access-Control-Allow-Origin，请求依然被拦截，只是少了 OPTIONS 这一步。

实际选型建议

判断用哪个模式，先问自己一个问题：“我需要从响应里拿东西吗？”

• 需要 JSON、下载文件、检查状态码 → 必须用 cors，并推动后端配置对应响应头；
• 只需发个请求（如通知第三方系统、打日志），不关心返回 → no-cors 可用，但要接受响应不可读；
• 服务端无法修改（如调用公开 webhook.site）→ 前端无法用 cors 成功读取，此时应引入后端代理，由服务端转发并添加 CORS 头，前端再请求同源代理接口。

今天关于《CORS与NO-CORS区别解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！