credentials 选项的三个取值分别代表：①omit（默认值），完全不发送 Cookie，同域亦不发；②same-origin，仅同源时发送 Cookie；③include，无论同域或跨域均发送 Cookie，但需服务端配合 Access-Control-Allow-Credentials: true 及非通配符 Origin。
credentials 选项的三个取值分别代表什么
Fetch 的 credentials 是一个控制请求是否携带 Cookie、HTTP 认证信息等凭据的开关，它只有三个合法值："omit"、"same-origin" 和 "include"。
默认值是 "omit" —— 这意味着即使当前页面和目标接口同域，也不会自动带上 Cookie。很多人踩坑就从这里开始：以为“同域就该带”，结果发现登录态没传过去。
-
"omit"：完全不发送 Cookie（哪怕同域）；服务端 Set-Cookie 响应头也会被浏览器忽略 -
"same-origin"：仅当请求 URL 与当前页面同源（协议 + 域名 + 端口完全一致）时才携带 Cookie -
"include"：无论跨域与否，都强制携带 Cookie（但前提是服务端明确允许，见下节）
跨域请求带 Cookie 必须和服务端配合
只设 credentials: "include" 不够，服务端必须响应 Access-Control-Allow-Origin 且不能为通配符 "*"，否则浏览器会直接拒绝响应。
例如后端 Express 中需显式设置：
res.header("Access-Control-Allow-Origin", "https://your-frontend.com");
res.header("Access-Control-Allow-Credentials", "true");
注意两点：
-
Access-Control-Allow-Origin必须写具体域名，不能是"*" -
Access-Control-Allow-Credentials必须为"true"字符串（不是布尔值） - 如果前端用的是 localhost:3000，后端也要把该地址列入白名单，否则开发期也失败
同域请求为什么有时也不带 Cookie
即使没跨域，credentials: "same-origin" 也可能不发 Cookie —— 常见原因有：
- 当前页面 Cookie 被标记了
HttpOnly或Secure，而页面非 HTTPS，导致浏览器不参与发送 - Cookie 的
SameSite属性为"Strict"或"Lax"，且请求触发方式不符合策略（比如表单提交、重定向、fetch 调用时机） - 用户开启了「阻止第三方 Cookie」或隐私模式，部分浏览器（如 Safari）会更激进地限制
调试时可检查 DevTools → Application → Cookies，确认目标域名下是否有有效且未过期的 Cookie，再看 Network 面板中请求头是否含 Cookie: 字段。
fetch 发送带 Cookie 请求的最小可行写法
以下是最简但可靠的写法，适用于大多数同域或已配置好 CORS 的跨域场景：
fetch("/api/user", {
credentials: "include"
});
如果只是同域调用，"same-origin" 更安全；若确定要跨域且后端已支持，则必须用 "include" 并确保服务端响应头合规。漏掉任一环节，Cookie 就不会出现在请求里，后端也就收不到登录态。
最容易被忽略的是：本地开发时前后端端口不同（如前端 3000、后端 8000），这已经属于跨域，"same-origin" 会失效，必须走 "include" + 后端 CORS 白名单配合。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
