Postman添加Cookie有三种方式：Header手动填写（需注意分号后空格）、Cookie管理器（域名必须精确匹配）、Pre-request Script动态注入（支持环境变量和URL编码）；需严格校验域名、Expires时间、Secure属性及协议一致性。
Postman 添加 Cookie 不需要先登录、也不必写脚本——只要你知道目标请求发给哪个域名，就能直接填进去。但填错域名、过期时间或格式，请求照样 401 或 302 跳转回登录页。
Cookie 域名必须和请求 URL 匹配
Postman 的 Cookie 管理器里填的 Domain 值，不是完整 URL，也不是带协议的地址，而是纯域名（或 IP）部分。比如请求是 https://api.example.com/v1/user，Domain 就得填 api.example.com；如果是 http://127.0.0.1:8080/login，Domain 就填 127.0.0.1。
常见错误：
- 填成
https://api.example.com或api.example.com/→ Cookie 不会自动带上 - 填成
.example.com却请求api.example.com→ 多数情况能匹配，但某些后端校验严格时会拒绝 - 本地开发用
localhost，但浏览器实际发的是127.0.0.1→ 域名不一致，Cookie 被丢弃
Header 里手动加 Cookie 最快，但格式不能错
在请求的 Headers 标签页里加一条 key 为 Cookie 的 header，value 是标准的 key=value 对，多个用分号 + 空格分隔。注意：分号后面必须有空格，否则某些服务端解析失败。
正确写法：PHPSESSID=abc123; user_token=xyz789
错误写法：PHPSESSID=abc123;user_token=xyz789（缺空格）
适用场景：
- 临时测试，只跑一两次
- Cookie 值是静态的（比如测试环境固定 session）
- 不想进 Cookie 管理器点点点
缺点：无法自动处理 Set-Cookie 响应，也不能跨请求复用。
用 Pre-request Script 动态注入 Cookie
当你需要根据环境变量、上一个响应或时间戳生成 Cookie 值时，Pre-request Script 是唯一可靠方式。它在每次发送前执行，比 Header 静态填写更灵活。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
示例：把环境变量 session_id 注入 Cookie
pm.request.headers.add({
key: 'Cookie',
value: `sessionid=${pm.environment.get('session_id')}`
});
注意点：
- 不能用
pm.cookies.set()—— 这个 API 只对 Cookie 管理器生效，且要求域名已存在 - 如果同时在 Header 里也写了
Cookie，脚本会覆盖它（Postman 按“脚本 → header → cookie manager”优先级合并） - 值里含特殊字符（如空格、分号）要 URL 编码，否则服务端可能截断
别忽略 Expires 和 Secure 属性
Postman Cookie 管理器里填的 Expires 时间，不是“提醒你过期”，而是真正控制是否发送。如果当前时间已超过该值，Postman 就不会把这个 Cookie 加进请求头——哪怕你还看着它显示在列表里。
另外，如果服务端设置了 Secure 属性（即只走 HTTPS），而你用 http:// 请求，Postman 默认也不会发送该 Cookie，即使域名、路径、时间都对。
所以看到 Cookie “明明填了却没发出去”，先检查：
- 系统时间是否准确（尤其虚拟机或 Docker 容器里时间不同步）
- 请求协议是否匹配
Secure要求 - 响应中是否有
Set-Cookie: ... Secure; HttpOnly，这种 Cookie 浏览器能存，Postman 无法读取也无法覆盖
真正难搞的从来不是怎么加，而是为什么加了没生效——盯住 DevTools Network 里的 Request Headers 和 Response Headers 对比，比翻文档快十倍。
