Fetch 跨域携带 Cookie 需同时满足：客户端设 credentials: 'include'，服务端响应头含 Access-Control-Allow-Credentials: true 且 Access-Control-Allow-Origin 指定具体源而非 *，Cookie 自身需设 SameSite=None; Secure 并匹配目标域名。
Fetch 默认不发送 Cookie，跨域时尤其需要显式配置才能携带凭证（如 Cookie、HTTP 认证信息）。关键在于两个地方：请求端设置 credentials 选项，服务端响应头正确声明 Access-Control-Allow-Credentials: true，且不能将 Access-Control-Allow-Origin 设为通配符 *。
客户端必须设置 credentials: 'include'
这是启用 Cookie 传输的必要条件。不设或设为 'omit'（默认值）时，浏览器完全忽略 Cookie；设为 'same-origin' 则仅同源时携带。
- 正确写法：
fetch(url, { credentials: 'include' }) - 如果后端部署在不同域名（如前端
https://a.com，后端https://api.b.com），必须用'include'才能发 Cookie - 注意：即使只读取 Cookie（如登录态校验），也要设此项，否则请求压根不带 Cookie 字段
服务端必须配合响应头
浏览器收到跨域响应后，会检查响应头是否允许凭据。若不满足以下全部条件，即便前端设了 include，也会被静默拦截（控制台报 CORS 错误，但无详细提示）：
-
Access-Control-Allow-Credentials: true— 必须精确为true，不能是字符串"true"或其他值 -
Access-Control-Allow-Origin必须指定**具体源**，例如https://a.com，不可为* - 如果用到了自定义请求头（如
X-Auth-Token），还需额外声明：Access-Control-Allow-Headers
常见错误：后端用 Access-Control-Allow-Origin: * + credentials: true，此时浏览器直接拒绝，因为二者互斥。
Cookie 本身需满足跨域发送条件
即使 Fetch 和响应头都配对了，Cookie 还得“愿意出门”——它得符合自身的安全策略：
-
SameSite属性不能是Strict或Lax（默认值通常是Lax）；跨域请求需设为SameSite=None - 必须同时设置
Secure（即SameSite=None; Secure），否则现代浏览器（Chrome 80+、Firefox 79+）会拒绝发送 - 确保 Cookie 的
Domain属性覆盖目标后端域名（例如后端是api.b.com，Cookie 的Domain可设为.b.com）
调试建议
遇到 Cookie 不生效，按顺序排查：
- 打开浏览器开发者工具 → Network 标签页 → 点击请求 → 查看 Request Headers 是否含
Cookie字段（没有说明前端未发出） - 查看 Response Headers，确认是否存在
Access-Control-Allow-Credentials: true和明确的Access-Control-Allow-Origin - 检查 Application → Cookies，确认该 Cookie 已存在、
SameSite值为None、勾选了Secure - 后端日志中打印原始请求头，验证
Cookie是否真的到达服务器（排除 CDN 或反向代理剥离）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
