前端无法通过 response.headers.get('set-cookie') 读取该头，是浏览器依据 Fetch 规范实施的安全硬约束，属主动屏蔽机制；Set-Cookie 被列为禁止响应头，JS 一律不可读取、遍历或检测其存在，旨在防止会话凭证泄露与劫持。
前端 JavaScript 无法通过 response.headers.get('set-cookie') 读取 Set-Cookie 头，这不是 bug，而是浏览器的**主动屏蔽机制**——它被明确写入 Fetch 规范，属于安全硬约束。
Set-Cookie 是受保护的响应头
浏览器将 Set-Cookie（以及 Set-Cookie2）列为“Forbidden Response Header Name”，意味着：
- 即使服务器确实在响应中发送了该头部，Fetch API 的
Headers对象也始终对其返回null； -
response.headers.has('set-cookie')永远返回false； - 遍历所有 header（
response.headers.forEach）时，Set-Cookie不会出现； - 这个限制适用于所有前端环境：普通 JS、Service Worker、Web Worker 均无例外。
为什么浏览器要这样设计？
根本目的是防止脚本窃取或干扰会话凭证：
-
Set-Cookie直接控制浏览器如何存储和发送 Cookie，是身份认证的核心环节； - 如果 JS 能读取它，就可能解析出 session ID、JWT 片段等敏感值，造成信息泄露；
- 若允许修改或伪造，攻击者可劫持用户会话、覆盖合法 Cookie，导致越权访问。
那怎么确认 Cookie 是否真的设置了？
不能靠读响应头，但有可靠替代方式：
立即学习“前端免费学习笔记（深入）”；
- 打开浏览器开发者工具 → Application（或 Storage）→ Cookies，直接查看当前域名下已生效的 Cookie 列表；
- 发起下一个请求，在 Network 面板中检查该请求的 Request Headers → Cookie 字段，看是否自动携带了预期值；
- 在页面 JS 中调用
document.cookie（注意：仅对非HttpOnly的 Cookie 可见）； - 后端配合：在设置 Cookie 后，额外返回一个轻量 JSON 字段（如
{"cookie_set": true, "user_id": "123"}），供前端间接确认状态。
常见误解与混淆点
以下情况常被误认为是“Set-Cookie 没生效”，其实与读取限制无关：
-
Cookie 显示为空：可能是
Secure属性导致 HTTP 环境下被丢弃，或Domain/Path不匹配当前 URL； -
跨域请求没带 Cookie：需确保请求配置了
credentials: 'include'，且服务端响应头含Access-Control-Allow-Credentials: true和精确匹配的Access-Control-Allow-Origin（不能为*）； -
SameSite 限制触发：若设为
Strict或Lax，第三方上下文（如 iframe、跳转）中不会发送，属预期行为。
