Fetch 默认不携带 Cookie，必须显式设置 credentials 选项（同源用 'same-origin'，跨域用 'include'），并配合服务端 CORS 头（Access-Control-Allow-Origin 精确指定、Access-Control-Allow-Credentials: true）及 Cookie 属性（Secure、SameSite=None 等）三者协同生效。
Fetch 请求默认不自动携带 Cookie，必须显式设置 credentials 选项才能让浏览器在请求中附带已有的 Cookie（如登录态、Session ID 等）。这不是“开启开关”那么简单，而是涉及前端配置、服务端响应头、以及 Cookie 自身属性三方面协同生效。
同源请求：设 credentials: 'same-origin'
当请求地址与当前页面同协议、同域名、同端口时（例如页面在 https://example.com，请求 /api/profile），只需加这一行：
fetch('/api/profile', { credentials: 'same-origin' })- 浏览器会自动带上该域下有效的 Cookie（包括
HttpOnly的） - 服务端无需额外 CORS 配置（同源不受 CORS 限制）
- 这是最常用、最安全的写法，语义清晰，避免误用于跨域场景
跨域请求：前端 + 后端必须同时满足条件
若请求目标是不同源（如页面在 https://app.example.com，调用 https://api.example.com），仅设 credentials: 'include' 不够，需三者齐备：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
前端：明确写
credentials: 'include' -
后端响应头必须包含：
-
Access-Control-Allow-Origin: https://app.example.com（不能是*） Access-Control-Allow-Credentials: true
-
-
Cookie 本身需由服务端设置为：
-
SameSite=None（允许跨站上下文发送） -
Secure（仅 HTTPS 传输，HTTP 环境下无效） - Domain 和 Path 匹配目标请求范围
-
Cookie 属性常见陷阱
即使代码和服务端头都正确，Cookie 仍可能不被携带，原因常出在自身设置上：
立即学习“Java免费学习笔记（深入）”；
-
SameSite=Lax或Strict会阻止多数跨域 GET 请求携带 Cookie（比如从链接跳转触发的 fetch） -
Secure在 HTTP 页面下完全失效——本地开发建议用https://localhost或启用 HTTPS 代理 -
Max-Age或Expires过期、Domain 不匹配、Path 不覆盖请求路径，都会导致浏览器忽略该 Cookie -
HttpOnly不影响自动携带，只限制 JS 读取，无需额外处理
替代方案：Token 更灵活可控
如果 Cookie 方案调试复杂（尤其开发环境无 HTTPS、多子域管理困难），推荐改用 Token：
- 登录成功后，后端返回 JWT 或随机 token，前端存入
localStorage或内存 - 后续请求通过
Authorization: Bearer xxx携带，不受SameSite、Secure限制 - 服务端验证 token 并关联用户身份，完全绕过浏览器 Cookie 策略
- 适合前后端分离、微前端、跨协议等场景
