cookie跨域失效本质是浏览器因路径、域名或协议变更触发重校验，导致不存不带；需聚焦域名匹配、协议一致性、samesite策略、cors凭据配置四断点排查。
流量切换后 Cookie 跨域失效，本质是请求路径、域名或协议发生变更，导致浏览器对 Cookie 的存储与携带规则被触发重校验。不是“Cookie 没发”，而是“发了但浏览器不认、不存、不带”。排查要聚焦在 域名匹配、协议一致性、SameSite 策略、CORS 凭据配置 这四个关键断点上。
看响应头：Set-Cookie 是否真被下发且属性合规
打开 Chrome DevTools → Network → 找登录/鉴权接口响应 → 查看 Response Headers 中的 Set-Cookie 字段：
- 有没有 Domain 属性？若缺失或写成
Domain=backend-api.com，而用户访问的是app.example.com，浏览器直接拒收；应设为Domain=.example.com（注意开头的点）以支持子域共享 - 有没有 Secure？流量切到 HTTPS 前端后，若 Cookie 带了
Secure但后端仍走 HTTP，该 Cookie 就不会写入；反之，切到 HTTPS 后未加Secure，Chrome 80+ 会静默丢弃 - 有没有 SameSite=None？跨域场景（如前端
fe.example.com调后端api.example.com）必须显式声明SameSite=None，否则默认 Lax 会阻止 POST/重定向等跨站请求携带 Cookie - 有没有 HttpOnly？它不影响 Cookie 生效，只影响 JS 读取；若你在
document.cookie里看不到，别急着认为没生效——只要请求头带了Cookie:，说明浏览器自己在用
看请求头：后续请求是否真的带上 Cookie
切换流量后，发起一个需鉴权的接口（比如 /user/profile），在 Network 面板检查该请求的 Request Headers：
- 是否存在
Cookie:字段？为空或缺失，说明浏览器根本没把 Cookie 带上 - 若存在但内容不包含预期的 session ID，可能是多个同名 Cookie 冲突，或 Path 不匹配（例如后端设
Path=/api，但前端请求的是/） - 确认请求发起时是否设置了
credentials: 'include'（fetch）或withCredentials: true（XMLHttpRequest / Axios）。没开这个开关，浏览器连试都不试带 Cookie
看跨域配置：CORS 和代理层是否“放行”了 Cookie
前后端不同源时，光有 Cookie 还不够，服务端必须明确允许凭据参与跨域：
- 响应头必须含
Access-Control-Allow-Origin: https://fe.example.com（不能是*） - 必须含
Access-Control-Allow-Credentials: true - 若走 Nginx 反向代理，还需检查：
–proxy_cookie_domain是否重写了 Domain 以匹配前端域名
–proxy_cookie_path是否把后端 Path（如/api）映射到了前端路径（如/）
– 是否在 proxy_pass 后补全了SameSite=None; Secure（尤其 Chrome 80+ 强制要求）
看终端环境：特别是 WebView 和 iOS 特殊限制
如果是 App 内嵌 H5 页面（尤其 iOS WKWebView），流量切换后失效更常见：
- WKWebView 默认不共享系统 NSHTTPCookieStorage，需在原生层调用
WKHTTPCookieStore同步 Cookie - iOS 14+ 对第三方 Cookie 限制更严，若流量切到非主域（如从
app.example.com切到login.example.com），需确保两个域名都配置了相同的Domain=.example.com且协议一致 - Android WebView 相对宽松，但仍需确认是否调用了
CookieManager.getInstance().setCookie()主动注入（尤其首次加载）
