Postman不会自动继承或猜测Cookie，必须通过静态复用（手动添加匹配域名/路径的Cookie）或动态提取（启用自动管理+解析Set-Cookie响应）两种可靠方式配置；Pre-request Script硬编码Cookie头常因不存入管理器、域不匹配或Secure缺失而失效。
Postman 无法在请求前“准备好”Cookie，除非你明确告诉它该用什么值、从哪来、作用域是否匹配——它不会自动猜、也不会跨请求继承未保存的响应头。
为什么 Pre-request Script 里直接写 pm.request.headers.add({ key: 'Cookie', value: 'xxx' }) 经常失效
这个写法看似能“提前加 Cookie”，但实际有三个硬限制：
- 它只影响当前请求的
Cookie请求头，不写入 Postman 的 Cookie 管理器，后续请求不会继承 - 如果服务端返回了
Set-Cookie（比如登录成功），而你没启用 Cookie 自动管理，这个新 Cookie 不会被保存，下个请求依然裸奔 - 手动拼的
Cookie: a=1; b=2值，若域名、Path、Secure 或 HttpOnly 属性不匹配目标接口，服务端会静默忽略（尤其常见于 HTTPS 接口要求 Secure 属性）
真正可靠的前置 Cookie 配置，只有两种路径
一种是“静态复用”，一种是“动态提取”，选错路径就注定要反复调试：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
静态复用：适用于 Cookie 长期有效、来源明确（比如从浏览器复制、或从旧测试记录里拷贝）。操作路径是：
Cookies按钮 →Add Cookie→ 填写Domain（必须和请求 URL 域名完全一致，含www.或不含都要对齐）、Path（通常填/）、Name和Value。注意：Postman 不校验 Domain 格式，填错就发不出去 -
动态提取：适用于登录后自动带出 Session ID 类 Cookie。必须开启 Cookie 自动管理（默认已开），且前置请求（如登录）要用
POST发送到正确 URL，并确保响应头含Set-Cookie。Postman 只有在收到合法Set-Cookie响应后，才会把值存进管理器并自动附到同域后续请求
跨环境切换时，Set-Cookie 名称不同导致提取失败怎么办
比如开发环境返回 t_iam_dev=xxx，生产环境返回 t_iam_prod=xxx，而你的脚本只写死提取 t_iam_dev。这时不能靠预请求脚本硬编码，得用条件逻辑：
- 在登录请求的
Tests里写 JavaScript，遍历pm.response.headers.get('Set-Cookie')的原始字符串，用正则匹配t_iam_.*?=开头的片段 - 提取后存为环境变量：
pm.environment.set('session_cookie', extractedValue) - 后续请求的
Pre-request Script中再用：pm.request.headers.upsert({ key: 'Cookie', value: pm.environment.get('session_cookie') }) - 关键点：别依赖
pm.cookies.get()，它只读 Cookie 管理器里的值，而管理器可能还没存进去（比如刚登录完还没刷新）
最常被忽略的是 Domain 匹配规则：Postman 要求请求 URL 的域名和 Cookie 管理器里填的 Domain 完全一致，包括子域层级和端口（:8000 也算）。少一个点、多一个端口，Cookie 就不会自动带上。
