Postman中手动添加的Cookie与自动保存的Cookie会叠加发送而非覆盖，导致请求头出现重复键或混杂值，引发服务端解析异常；应通过Cookies面板确认实际发出的Cookie，并依场景选择关闭手动Cookie头、清空管理器后手动设置，或用Pre-request Script精确控制。
Postman里手动加的Cookie和自动保存的Cookie会叠加发送
Postman默认会把「手动在Headers里填的Cookie头」和「自动从Set-Cookie响应中存下来的Cookie」一起发出去，不是覆盖，是拼接。结果就是请求头里出现两个Cookie字段，或者一个字段里混着两套值，比如：Cookie: JSESSIONID=abc123; user_token=xyz789; JSESSIONID=def456。服务端解析时可能只取第一个JSESSIONID，也可能直接报错（如Spring Boot的Invalid cookie header），更常见的是会话失效、权限错乱。
根本原因在于：Postman的Cookie管理器（Cookies面板）和Headers里的Cookie头属于两个独立通道，它不会帮你去重或优先级判断。
- 手动在Headers里写
Cookie: key=val→ 绝对优先，强制生效，但不参与自动管理 - 通过登录请求自动获取的Cookie → 存在Cookie管理器中，按域名匹配自动注入，但前提是没被Headers里的
Cookie头“屏蔽” - 两者共存时，Postman实际发出的请求头里会出现多个
Cookie条目（HTTP/1.1允许，但多数服务端只认第一个）
如何判断当前请求到底发了哪些Cookie
别猜，直接看。每次发送请求后，点右上角Cookies链接，打开Cookie管理面板，顶部会显示「This request used cookies from」，后面跟着来源说明：可能是Cookie Jar (auto)，也可能是Request headers，或两者都列出来。再往下拉，能看到所有实际参与本次请求的Cookie条目，包括域名、名称、值、过期时间——这才是真实发出的内容。
注意：如果这里显示Request headers，且你没在Headers里手动加Cookie头，那大概率是某个预请求脚本偷偷塞了pm.request.headers.add({key: 'Cookie', ...})，得去Pre-request Script里翻一遍。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 检查Headers选项卡：确认有没有手写的
Cookie键 - 检查Pre-request Script：搜索
Cookie、headers.add、setCookie等关键词 - 检查环境变量或全局脚本：有些团队会用全局Pre-request脚本统一补Cookie，容易被忽略
彻底避免重复的三种实操方案
目标不是“删掉一个”，而是让系统只走一条路径。选哪种取决于你的测试场景是否需要动态会话管理。
- 要长期复用登录态（比如跑一整套业务流）：关掉Headers里的
Cookie头，完全依赖Cookie管理器。进设置 →Settings→ 关闭Automatically persist cookies以外的所有干扰项，确保登录请求返回的Set-Cookie能被正确捕获并自动带入后续请求 - 要精确控制每次请求的Cookie（比如压测不同用户、绕过登录态）：删掉Cookie管理器里对应域名的所有条目，只在Headers里手动写
Cookie头。操作路径：点击右上角Cookies→ 选域名 → 点垃圾桶图标清空 - 混合场景（如大部分请求走自动，个别请求需覆盖）：用Pre-request Script主动清除再重设。例如在特定请求的
Pre-request Script里写：pm.cookies.jar().clear("https://api.example.com");<br>pm.request.headers.upsert({key: "Cookie", value: "sessionid=override123"});
容易被忽略的坑：HttpOnly Cookie和跨域域名匹配
即使你清空了Cookie管理器，某些Cookie依然发出去了——尤其是标记了HttpOnly的JSESSIONID。Postman无法读取或修改这类Cookie，但它会照常发送已持有的副本。更麻烦的是域名匹配逻辑：Postman把https://api.example.com和https://staging-api.example.com视为两个完全不同的域，Cookie不会共享。所以切环境时，光清Cookie管理器不够，还得确认当前请求URL的域名和你存Cookie时用的域名是否严格一致（连www前缀、端口号都不能差）。
最稳妥的做法是：每次切换环境前，先点Cookies面板，挨个检查每个域名下的条目，手动删掉所有非当前环境的残留。别信“我刚切了环境变量，Cookie就自动换了”这种直觉。
