fetch 默认不发送 cookie 和认证头，必须显式设置 credentials: "include" 才能在跨域请求中携带凭证；同时后端须返回 access-control-allow-origin（精确域名，不可为*）和 access-control-allow-credentials: true，且 cookie 需含 secure 与 samesite=none。
Fetch 默认不发送 Cookie 和认证头，跨域时需显式开启凭证支持，否则浏览器会直接拦截请求或服务端拒绝。
设置 credentials 选项为 "include"
这是关键一步。默认值是 "omit"，意味着不携带任何凭证；"same-origin" 只在同源时发 Cookie；只有设为 "include" 才会在跨域请求中带上 Cookie、HTTP 认证信息等。
- 必须在
fetch调用中明确指定：credentials: "include" - 即使目标域名和当前页面同协议、同端口但不同子域（如
app.example.com→api.example.com），也算跨域，仍需"include" - 如果后端没配合设置响应头，仍会失败——这只是客户端“愿意发”，不代表服务端“允许收”
后端必须返回正确的 CORS 响应头
浏览器检查响应头决定是否放行带凭证的响应。仅前端设 credentials: "include" 不够，服务端必须响应：
-
Access-Control-Allow-Origin：不能是通配符*，必须是精确匹配的源（如https://your-app.com） -
Access-Control-Allow-Credentials: true：明确允许携带凭证 - 可选但推荐：
Access-Control-Allow-Headers列出客户端实际发送的自定义头（如Authorization）
例如 Node.js + Express 中：
res.header("Access-Control-Allow-Origin", "https://your-app.com");
res.header("Access-Control-Allow-Credentials", "true");
res.header("Access-Control-Allow-Headers", "Content-Type, Authorization");
确保 Cookie 符合安全要求
即使前端和服务端都配置正确，Cookie 本身也需满足条件才能被携带：
- 服务端 Set-Cookie 时需包含
SameSite=None和Secure（HTTPS 环境下必需） - 例如：
Set-Cookie: sessionid=abc123; Path=/; Domain=example.com; Secure; SameSite=None - 开发环境若用 HTTP，
Secure无法生效，建议本地用 HTTPS（如https://localhost）或临时禁用浏览器安全策略测试（仅调试）
注意预检请求（Preflight）的影响
当请求含自定义头（如 Authorization）或非简单方法（如 PUT、DELETE），浏览器会先发 OPTIONS 预检。此时：
- 预检响应也必须包含
Access-Control-Allow-Credentials: true -
Access-Control-Allow-Origin同样不能为* - 确保后端对 OPTIONS 请求正确响应，且不跳过 CORS 头设置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
