Postman对同名Cookie按Path和Domain匹配规则处理：完全一致则后添加覆盖先添加，否则共存；手动添加时若忽略Domain或Path易致错配失效，清Cookie需同步清理管理面板与请求Tab上下文。
Postman 里出现同名 Cookie（比如多个 JSESSIONID 或重复的 token）时，不是“覆盖就完事”，而是会按规则合并、覆盖或静默丢弃——结果往往是你发出去的请求带了错的值，登录态失效、权限校验失败、接口返回 401 却查不出原因。
Postman 怎么处理同域名下的同名 Cookie
Postman 的 Cookie 管理器对同一域名下同名 Cookie 的行为是：后添加的会覆盖先添加的，但前提是它们的 Path 和 Domain 完全一致。如果两个 JSESSIONID 的 Path 分别是 /app1 和 /app2，那它们会被同时保留，并在匹配路径时分别发送。
- 浏览器式逻辑：Postman 模拟的是浏览器的 Cookie 发送机制，不是简单地拼接字符串
- 实际影响：你手动加了一个
token=abc，又通过登录接口自动存了一个token=xyz，若两者Path=/且没设Domain，后者大概率覆盖前者 - 验证方式：发请求后点响应头旁的
Cookies标签，看实际发出的是哪个值
如何避免手动添加时误覆写关键 Cookie
手动在 Cookie 管理面板添加时，最容易踩的坑是只填了 Name 和 Value，却忽略 Domain 和 Path 导致作用域错配。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 务必填对
Domain：输入api.example.com，不是http://api.example.com，也不是example.com（除非你真要跨子域） -
Path要精确：如果接口只在/v2/user下需要该 Cookie，就填/v2或/v2/，别偷懒写/ - 删之前先确认：点击域名右侧的
X是删整个域名下所有 Cookie；点单个 Cookie 后的X才是删那个键值对 - 临时绕过：在请求 Settings 里勾选
Disable cookie jar，可彻底禁用自动 Cookie 行为，只走 Headers 手动传
用 Headers 直接传 Cookie 适合什么场景
当你要确保某个请求**绝对不混入其他 Cookie**（比如测试无状态鉴权、复现特定 header 组合、绕过会话污染），Headers 方式最干净。
- 格式必须严格：
Cookie: JSESSIONID=abc123; token=xyz789，键值间用=，对之间用分号+空格 - 不会受 Cookie 管理器中任何设置影响，也不会被后续请求复用
- 缺点：不能自动更新（比如登录后拿到新
token，得手动改 Headers）；不适合多请求串联场景 - 配合 Pre-request Script 可动态注入：
pm.request.headers.add({ key: 'Cookie', value: `token=${pm.variables.get('auth_token')}` });
为什么清 Cookie 后还是带着旧值
常见原因是没清对地方——Postman 的 Cookie 存储有两层：全局 Cookie Jar 和当前请求 Tab 的隐式会话上下文。你清了管理面板里的，但请求 Tab 可能还缓着上一次响应带回来的 Set-Cookie。
- 正确清理顺序：先在 Cookie 管理面板删掉对应域名 → 再关掉当前请求 Tab → 重新打开新 Tab 发请求
- 更彻底的办法：点右上角齿轮 →
Settings→Clear all cookies（注意这是全局清除） - 如果用了 Interceptor 同步浏览器 Cookie，记得也在 Chrome 里清一遍，否则切回 Postman 还会同步回来
- 网页版用户额外注意：它依赖服务端代理转发请求，本地清除 Cookie 后，需等服务端缓存过期（通常几秒），或手动刷新代理会话
同名 Cookie 不是 bug，是 HTTP 协议和 Postman 设计共同作用的结果。真正容易被忽略的，是 Domain 和 Path 这两个字段看似可选，实则决定 Cookie 是否生效、是否冲突、是否被浏览器或 Postman 丢弃——填错一个字符，就可能让整个会话链路静默中断。
