前端无法通过 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 均无例外。

为什么浏览器要这样设计？

根本目的是防止脚本窃取或干扰会话凭证：

HISUI 前端框架开发指南（IRIS版）

HISUI 前端框架基础开发指南。HISUI 是基于 easyui 二次开发的 jQuery UI 组件库，专为医疗信息系统设计。当涉及 HISUI 组件开发、jQuery easyui 表格/表单/布局/窗口、医疗系统前端页面编写时使用此 skill。 涵盖 40 个组件的官方文档参考，支持声明式与编程式两种初始化方式，提供 $cm/$m 数据访问方法。

下载

• 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、跳转）中不会发送，属预期行为。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！