fetch api 默认不发送凭证，需显式设置 credentials 为 'same-origin'（同源）或 'include'（跨域），并配合服务端 cors 头 access-control-allow-credentials: true 和精确的 access-control-allow-origin。
在 Fetch API 中使用 credentials 选项控制是否发送 Cookie、HTTP 认证信息等凭证，关键在于明确设置值并配合服务端 CORS 配置。默认情况下 Fetch 不发送凭证，即使同源请求也需显式声明。
credentials 可选值及适用场景
credentials 是一个可选的配置项，有三个合法值：
-
'omit'：从不发送凭证（默认值），即使同源也不带 Cookie 或授权头 -
'same-origin'：仅当请求 URL 与当前页面同源时才发送凭证（最常用，安全且符合预期） -
'include'：始终发送凭证，包括跨域请求（需服务端明确允许，否则被浏览器拦截）
同源请求下启用凭证的写法
即使目标地址是同源（比如都来自 https://example.com），也要手动设为 'same-origin' 才会携带 Cookie：
这样浏览器会在请求头中自动带上 Cookie 和 Authorization 等凭证字段（如果存在）。
服务端必须配合设置 CORS 头
若使用 'same-origin'，服务端无需额外处理 CORS 凭证相关头（因为同源不受 CORS 限制）。但若误用 'include' 或跨域场景，则服务端必须响应以下头，否则浏览器会拒绝返回：
-
Access-Control-Allow-Origin：不能为通配符*，必须指定确切源（如https://example.com） -
Access-Control-Allow-Credentials: true：显式允许携带凭证
常见误区提醒
很多人以为同源请求“天然”带 Cookie，其实 Fetch 默认禁用凭证，这是与传统 XMLHttpRequest 的重要区别。遗漏 credentials: 'same-origin' 会导致登录态失效、401 错误等问题。另外，credentials: 'include' 在同源请求中也能工作，但语义不精确，建议优先用 'same-origin'。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
