Postman“清除Cookie”按钮只清当前域名及当前会话的Cookie，非全局失效；需手动选域名后清除，或通过DevTools逐域清理并重启Postman。
Postman里“清除Cookie”按钮为什么没用？
点击 Clear All Cookies 后请求还是带着旧 SessionID，不是按钮失灵，而是它只清当前域名下、当前会话（即当前标签页或当前集合 Runner）里的 Cookie。如果你在多个标签页里分别登录过不同账号，或者用 Collection Runner 跑过历史测试，那些 Cookie 仍躺在其他会话上下文中，根本不会被这个按钮触达。
真正起效的操作是：先确认你要清理的目标域名（比如 api.example.com），再进 Cookies 面板，从左侧域列表中手动选中它，再点右侧的 X 删除单条，或点底部 Clear All Cookies —— 这个“全部”仅指该域名下的全部，不是全局。
如何一次性清掉所有环境的登录态？
Postman 没有“全局清空所有域名 Cookie”的一键按钮。但你可以用控制台强制刷新底层存储：
- 快捷键
Ctrl+Shift+I（Windows/Linux）或Cmd+Option+I（macOS）打开 DevTools - 切到
Application→Cookies标签页 - 左侧展开所有域名，逐个右键 →
Clear - 关掉 DevTools，重启 Postman（不是刷新窗口），否则部分缓存 Cookie 可能被重新载入
注意：Disable cookie jar 开关（在请求 Settings 里）只是临时禁用自动携带，不删除已存 Cookie；它适合临时绕过认证调试，但不能替代清理。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
Pre-request Script 自动删 Cookie 的风险点
有人在登录请求前写脚本调用 pm.cookies.jar().clear()，想确保每次都是干净会话。这看似合理，但容易踩两个坑：
- 它只清当前请求所属域名的 Cookie，如果登录接口和业务接口域名不同（比如
auth.example.com登录，api.example.com调用），clear()对后者无效 - 若脚本放在集合根目录的 Pre-request，而集合里混着多个环境（dev/test/prod），执行时会把所有环境的同域名 Cookie 全清掉，导致你刚在 dev 测完，切到 test 就得重登录
- 更稳妥的做法是：用
pm.cookies.jar().set(domain, name, '')显式覆盖关键字段（如token、sessionId），而不是暴力清空
为什么改了环境变量，Cookie 还是发给旧域名？
Postman 的 Cookie 是按完整域名（含端口）隔离存储的。比如你把环境变量 {{base_url}} 从 http://localhost:3000 改成 https://api-staging.example.com，但之前在 localhost:3000 下存的 Cookie 不会自动迁移或失效——它们还老老实实待在 localhost:3000 的存储槽里。
这时候最常被忽略的是：你发请求时 URL 看似变了，但实际发出的 Host 头可能仍是旧的（尤其用了代理或重写规则）。建议在请求发送后，点 Headers 标签页，展开 hidden 查看真实发出的 Cookie 头内容，再对照 Cookies 面板里对应域名的列表，确认是否真的加载了目标域的 Cookie。
