Postman脚本无法直接读写Cookie存储，仅能通过手动设置Cookie请求头或解析Set-Cookie响应头存环境变量来实现动态管理。
Postman 中用脚本读写 Cookie 的真实限制
Postman 本身不提供直接操作 Cookie 存储的 JS API（比如没有 document.cookie），也不能在 Pre-request Script 或 Tests 里调用浏览器 Cookie 接口。你看到的「Cookie」面板只是 Postman 自己维护的一份请求级 Cookie 缓存，脚本能干预的只有「下一次请求头里发什么 Cookie」，而不是“修改本地 Cookie 管理器里的值”。
Pre-request Script 中手动注入 Cookie 头
这是最常用、也最可控的方式：绕过 Cookie 管理器，直接拼 Cookie 请求头。适合需要动态生成、加密或依赖环境变量的场景。
- Postman 不会自动合并你手动设置的
Cookie头和 Cookie 面板里的值——一旦你在脚本里设置了pm.request.headers.add()，它就会完全覆盖面板行为 - 示例：把环境变量
auth_token注入为 Cookie
const token = pm.environment.get("auth_token");
pm.request.headers.upsert({key: "Cookie", value: `session_id=${token}; path=/; HttpOnly`});
-
upsert()比add()更安全，避免重复添加同名头 - 注意：
HttpOnly是只读标记，加不加都不影响发送，但服务端可能据此拒绝解析；实际发送时它只是字符串的一部分
Tests 脚本中提取响应 Set-Cookie 并存为环境变量
如果你需要“更新 Cookie”，本质是解析响应头里的 Set-Cookie，提取关键字段（如 value、expires），再存进环境变量供下次请求用。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- Postman 不会自动把
Set-Cookie写入 Cookie 面板（除非你打开「Automatically persist cookies」且没禁用） - 手动解析更可靠：避免因多条
Set-Cookie、逗号分隔、空格/引号导致解析失败 - 示例：提取
access_token=xxx并保存
const cookieHeader = pm.response.headers.get("Set-Cookie");
if (cookieHeader) {
const match = cookieHeader.match(/access_token=([^;]+)/);
if (match && match[1]) {
pm.environment.set("access_token", match[1]);
}
}
- 别依赖
pm.cookies.get()——它只读 Cookie 面板当前缓存，不是最新响应值 - 如果服务端返回多个
Set-Cookie，pm.response.headers.get("Set-Cookie")只返回第一个（Postman v10+ 改为返回全部拼接字符串，需按换行切分）
为什么不能用 pm.cookies.clear() 或 pm.cookies.jar().set() 实现“动态更新”
pm.cookies.jar() 看似能操作 Cookie，但它只在当前请求生命周期内生效，且必须配合域名、路径、协议三元组调用 set()，而 Postman 的 Cookie jar 是沙箱化的，不暴露底层存储接口。
-
pm.cookies.jar().set()必须传完整 URL（如"https://api.example.com"），不能只传域名；路径也必须精确匹配（"/"和"/v1"视为不同） - 即使成功 set，也不会反映在 Cookie 面板 UI 上，后续请求是否携带取决于你是否启用了「Send cookies with request」开关
- 常见误操作：
pm.cookies.jar().set("key", "val")—— 缺少 URL 参数，静默失败
真正稳定的链路只有两条：要么用脚本直写 Cookie 头，要么解析 Set-Cookie 响应头后存环境变量再手动注入。中间任何试图“改 Cookie 面板状态”的尝试，都会因 UI 与脚本不同步而失效。
