上线后 OPTIONS 预检一直 401，跨域头也加了，为啥浏览器还报跨域？

结论：线上浏览器报跨域，不一定是缺 Access-Control-Allow-Origin。按 2026 年项目交付习惯，如果请求带 Cookie、Authorization 或使用 PUT/DELETE，浏览器会先发 OPTIONS 预检；预检一旦被鉴权中间件拦成 401，后面补再多跨域响应头也放不出去。常见做法是让 OPTIONS 在鉴权前放行，再按来源、方法、头部、凭证四层核对。只加一个响应头，通常覆盖不了这些场景。

本地能通，为什么上线才报跨域？

本地开发常用 devServer 代理，把 /api 转到后端，浏览器看到的是同源请求，自然不触发跨域检查。上线后前端在 www 域名、接口在 api 域名或不同端口，浏览器判定为跨源，才按 CORS 规则要求服务端授权。报错是浏览器安全策略，不是服务端直接拒绝；服务端可能已返回数据，但浏览器不会把响应交给前端 JS。

要不要处理预检，先看请求类型。简单请求限定 GET、HEAD、POST，Content-Type 只能是 application/x-www-form-urlencoded、multipart/form-data 或 text/plain，且无自定义头。突破任一条，比如 PUT、DELETE、PATCH，或带 Authorization、X-Token，浏览器先发 OPTIONS 预检，通过后才发真实请求。

只加 Allow-Origin 为什么常常不够？

• 简单请求：不带凭证、无自定义头时，返回 Allow-Origin 等少量头可能够用。
• 预检请求：非简单方法或自定义头触发 OPTIONS，服务端要返回 Allow-Methods、Allow-Headers，且预检本身不能被鉴权拦截。
• 带凭证请求：前端设置 credentials: include，服务端必须返回具体 Origin 且 Allow-Credentials: true，不能用 *。

很多线上问题不是 CORS 头没加，而是 OPTIONS 请求不带 Cookie 或 Token，被登录鉴权中间件先拦成 401 或跳登录页。预检失败后，真实请求根本发不出去，控制台却显示跨域。

四层核对法与常见错配

1. 来源层：校验请求 Origin 是否在白名单内，返回单个匹配的 Allow-Origin。生产环境不建议反射任意 Origin。
2. 方法层：Allow-Methods 要包含实际方法，常见为 GET、POST、PUT、DELETE、PATCH、OPTIONS。
3. 头部层：Allow-Headers 要列出前端实际发送的自定义头，如 Authorization、Content-Type、X-Requested-With。
4. 凭证层：带 Cookie 或 Authorization 且 credentials 为 include 时，Allow-Credentials 要为 true，Allow-Origin 不能为 *。

核对时看浏览器 Network 面板的 OPTIONS 响应头，比只看控制台结论可靠。常见错配包括：Allow-Origin 动态反射未校验、Nginx 和应用同时写 CORS 头导致 multiple values、只处理实际请求不处理 OPTIONS。

方案对比：网关统一、应用层逐个配、开发代理

按 2026 年常见交付习惯，跨域处理有三条路径，选择取决于服务数量、域名策略和团队边界。

• 网关统一处理：在入口网关维护 Origin 白名单、预检放行和响应头注入。配置集中、上线快；风险是白名单过宽。经验区间：规则配置约 0.5~2 人天，视域名数量和鉴权链路而定。
• 应用层逐个配：在框架中间件按路由配置。贴合业务；服务多时容易漏配、重复配，改一次白名单要发多个服务。经验区间：单服务约 0.5~1 人天，多服务叠加常见到 3~5 人天。
• 开发代理：devServer 把 /api 代理到后端，浏览器看同源。本地联调省事；不能带到生产，生产仍需真实 CORS 或同域反向代理。

如果前后端最终同域部署，比如通过 Nginx 把 /api 反向代理到后端，浏览器看到的始终是同源，CORS 配置需求会大幅减少。这也是预算和周期紧张时常见的折中做法。

交付现场：预检被鉴权拦早了的代价

有一次项目周期紧，前后端并行开发，接口鉴权已经上线。前端带 Authorization 发 PUT，预检 OPTIONS 被鉴权中间件拦成 401，浏览器直接报跨域。约束条件是鉴权不能整体放开，接口也不能延迟上线。做法是在网关或鉴权中间件里先把 OPTIONS 放行并返回 204，再补 Allow-Methods 和 Allow-Headers，同时把预检白名单限定在已知来源。结果是联调恢复，但代价是上线后才补时，前端联调可能返工半天到一天，严重时影响提测节点。这类修复影响常见区间在 0.5~1 人天，越晚发现越容易拖进度。

适用与不适用边界

需要认真处理 CORS 的场景：前端与接口不同域或不同端口、需要跨域携带 Cookie 或 Authorization、接口被多个前端域名调用、使用 PUT/DELETE/PATCH 或自定义头。这些情况下，只靠一个响应头通常不够，预检、凭证和白名单至少要覆盖到。

反过来，同源部署、通过 Nginx 反向代理统一域名、移动端原生请求、服务端之间的 HTTP 调用，都不受浏览器同源策略约束，不需要配 CORS。内网服务调用如果报错，优先查网络策略、认证方式或协议，而不是加跨域响应头。边界可以记成：跨域是浏览器行为，发生在浏览器里的跨源请求才需要 CORS；服务端到服务端的调用不在这个范围内。

常见问题

本地代理能通，上线跨域，是不是代理没配到生产？

开发代理只解决本地浏览器的同源问题，生产需要真实 CORS 响应头或同域网关转发，代理配置不会自动带到生产，需单独核对生产入口。

Allow-Origin 设成 * 为什么带 Cookie 还失败？

带凭证时规范不允许 Allow-Origin 为 *，必须返回具体来源，并同时设置 Allow-Credentials: true，前端也要携带 credentials。

预检 OPTIONS 返回 200 但浏览器还报错，可能漏了什么？

预检响应需要包含 Allow-Methods、Allow-Headers，且不能被鉴权中间件拦截成登录页或 401，任一不匹配都会导致预检失败。

多个域名都要访问，Allow-Origin 可以写多个吗？

响应头不支持逗号分隔多个来源，常见做法是按请求 Origin 白名单校验后返回单个匹配值，或由网关统一维护白名单。

内网服务之间调用报跨域，也要配 CORS 吗？

跨域是浏览器同源策略的限制，服务端之间的 HTTP 调用不受 CORS 约束；内网调用报错通常是网络、认证或协议问题。

行动上，先判断请求是否同源、是否带凭证、是否触发预检，再决定代理、反向代理还是 CORS 响应头。适用边界：浏览器内跨源调用需要处理 CORS；同源部署、服务端调用和原生客户端不必套用。按交付验收清单核对预检和实际请求两组响应头，能减少上线返工。