跨域请求带不上Cookie，别只盯着CORS

前端页面部署成功，接口在工具里也能访问，浏览器却提示跨域错误。加上几个响应头之后，请求终于通了，登录状态还是丢失。继续把配置改成星号，又遇到新的报错。

这类问题经常是几套规则叠在一起。CORS 决定浏览器是否允许页面脚本读取跨来源响应；请求是否携带 Cookie，还受到请求选项、Cookie 属性和浏览器隐私策略的共同影响。先把这些条件分开检查，排查会清晰很多。

浏览器所说的来源，由协议、主机和端口共同决定。页面位于 https://app.example.com，接口位于 https://api.example.com，两者主机不同，属于跨来源。但它们可能仍然属于同站点。跨来源和跨站点是两个概念，不能看到子域名不同就直接断定需要 SameSite=None。

假设页面确实要向另一来源的接口发送 Cookie，可以在请求中明确指定：

const response = await fetch('https://api.example.net/profile', {
  credentials: 'include'
});

if (!response.ok) throw new Error('用户信息读取失败');
const profile = await response.json();

服务端对应的响应需要允许具体来源，并允许凭证：

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: Origin

携带凭证的场景不能把允许来源设为 *。如果服务需要支持多个前端来源，应先根据明确的白名单校验请求中的 Origin，再返回被允许的具体来源。直接原样反射任意来源，会把本应受保护的响应暴露给不受信任的页面。

如果请求使用 JSON、非简单方法或某些自定义头，浏览器可能先发送 OPTIONS 预检。例如请求携带 X-CSRF-Token，预检响应需要允许相关方法和请求头。预检通过之后，实际响应也必须带上正确的 CORS 头，不能只给 OPTIONS 配好。

预检请求通常不携带用户凭证，因此不要让登录中间件因为“没有 Cookie”就把它拦截到登录页。可以在限定的来源、方法和头范围内处理预检；真正的业务请求仍然需要正常执行身份和权限检查。

接下来检查 Cookie 本身。Domain 和 Path 要覆盖实际请求地址，Secure 要与 HTTPS 使用条件匹配。跨站点场景如果确实需要携带 Cookie，通常需要 SameSite=None; Secure；但这只是必要条件的一部分，浏览器仍可能根据第三方 Cookie 或存储分区策略限制它。

因此，CORS 配对了，不能保证跨站 Cookie 一定可用。对于可控的系统架构，把页面与接口部署在合适的同站点范围内，或者通过同源入口转发请求，往往比不断放宽响应头更容易维护。具体选择仍要符合账号体系和部署边界。

还需要记住，浏览器阻止脚本读取响应，并不一定意味着请求没有到达服务器。有些简单请求可以先发送，再在读取响应时受到限制。因此 CORS 不能充当服务端鉴权，也不能单独承担防止跨站请求伪造的任务。涉及状态变更时，仍需根据会话方案检查来源并使用合适的 CSRF 防护。

排查时可以按顺序看网络面板：是否有 OPTIONS，它是否成功，实际响应头是什么，请求是否携带 Cookie。再到浏览器的 Cookie 面板检查属性和被阻止的具体原因。不要只因为接口工具成功，就认为浏览器也应该成功；接口工具通常不会替你执行浏览器的跨来源读取规则。

最后用真实 HTTPS 域名验证登录、刷新和退出流程，并覆盖目标浏览器。把“能读响应”“会带凭证”“服务端认可身份”分别确认，比一次加上一长串允许头更容易找到根因。