前后端分离后跨域和 Cookie 携带问题怎么解决

跨域和 Cookie 携带是两件独立的事：跨域靠后端 CORS 响应头解决，Cookie 带不上则要同时满足三个条件——前端显式开启凭证模式（axios withCredentials: true / fetch credentials: 'include'）、后端 Access-Control-Allow-Origin 回写具体域名而不是 *、Cookie 本身设置 SameSite=None; Secure。如果这三条都做对了还不行，最稳的方案是干脆用 Nginx 或 Vite 代理把前后端变成同源，从根上绕开这两个问题。

跨域和 Cookie 携带到底是不是同一个问题

结论：不是，报错信息完全不同，必须分开排查。

跨域报的是 Access to XMLHttpRequest at ... has been blocked by CORS policy，这是浏览器拦截了响应内容的读取——请求其实已经打到服务器了，服务器也返回了 200，只是浏览器不把结果交给 JS。Cookie 不携带则表现为：接口返回 200，但后端拿到的 session 是空的，或者用户刷新页面就掉登录态。

所以「跨域解决了但登录还是失败」是常态。跨域只看响应头，Cookie 还要看请求头里有没有 Cookie: 这一行，以及浏览器 Cookie 存储里的 SameSite、Secure、Domain 三个字段。

后端 CORS 响应头该怎么配

结论：至少配 4 个头，且开了凭证就不能用 *。

以 Node/Express 为例：

app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', req.headers.origin); // 回写具体来源
  res.setHeader('Access-Control-Allow-Credentials', 'true');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,OPTIONS');
  if (req.method === 'OPTIONS') return res.sendStatus(204); // 预检直接放行
  next();
});

三个易踩的坑：一是 Access-Control-Allow-Origin: * 和 Allow-Credentials: true 同时出现时，浏览器会直接拒绝该响应，必须回写 req.headers.origin；二是带 Origin 白名单校验，不能无条件回写，否则等于开放任意站点携带 Cookie 调你的接口；三是 Content-Type: application/json 属于非简单请求，会先发一次 OPTIONS 预检，预检必须返回 2xx，且可以用 Access-Control-Max-Age: 86400 把预检结果缓存 24 小时，减少一半请求量。

前端要改哪一行代码

结论：axios 改一个全局配置，fetch 改一个参数，二者不通用。

axios：axios.defaults.withCredentials = true，或在单个请求里写 { withCredentials: true }。
原生 fetch：fetch(url, { credentials: 'include' })，注意默认值是 same-origin，跨域时不带 Cookie。
jQuery：$.ajax({ xhrFields: { withCredentials: true } })。

只改前端不改后端，会得到 The value of the 'Access-Control-Allow-Credentials' header in the response is '' 这类报错，两边必须同时改。

Cookie 设了 SameSite 为什么还是带不上

结论：Chrome 80 起 SameSite 默认值是 Lax，跨站请求一律不带 Cookie，必须显式写 None 且同时加 Secure。

一条能跨站携带的 Cookie 长这样：

Set-Cookie: sid=abc123; Path=/; Domain=.example.com; HttpOnly; Secure; SameSite=None; Max-Age=604800

Secure 要求 HTTPS，唯一的例外是 localhost，Chrome 允许在 http://localhost 下设置 Secure Cookie。Domain 写 .example.com 可以让 a.example.com 和 api.example.com 共享；但如果前后端在完全不同的顶级域（比如前端 a.com、后端 b.com），那就是真正的第三方 Cookie，Safari 的 ITP 默认拦截，Chrome 也在收紧，这条路不可靠。

有没有一劳永逸的方案

结论：有，反向代理。让浏览器眼里只有同源。

Nginx 配置：

location /api/ {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

开发环境用 Vite：

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': { target: 'http://127.0.0.1:8080', changeOrigin: true }
    }
  }
}

代理之后，前端请求 /api/user，浏览器认为还是访问自己的域名，没有跨域，Cookie 天然携带，SameSite、Secure、CORS 三个问题一次性消失。另一种替代是 Token 方案：登录后把 JWT 放 Authorization: Bearer xxx 头里，不受 SameSite 限制，但要注意 token 存内存、刷新靠 HttpOnly Cookie 承载，别放 localStorage 以免 XSS 直接偷走。

排查清单

打不开登录态时按顺序查：DevTools → Network → 该请求的 Request Headers 里有没有 Cookie:；没有就查 Application → Cookies 里的 SameSite/Secure/Domain；有 Cookie: 但后端拿不到，就查后端是否跨了不同域名解析（Domain 写错）或 session 存储是否丢了。Response Headers 里则确认 Access-Control-Allow-Credentials: true 和 Access-Control-Allow-Origin 是具体域名。

总结一下：跨域靠 CORS 四个响应头，Cookie 靠前端 withCredentials + 后端不用 * + Cookie 写 SameSite=None; Secure 三件套；但生产环境最省心的做法仍然是反向代理做到同源，或者改用 Authorization 头传 Token。先判断你的前后端是不是同一个顶级域，是就走代理，不是就老实配 None + Secure 并接受 Safari 可能拦第三方 Cookie 的现实。