退出后Postman仍携带旧Cookie，因Cookie Jar机械复用已存Cookie；需检查Cookie Manager是否清空、请求Headers中Cookie是否消失，并确保服务端退出响应含匹配Domain/Path的Set-Cookie清除指令。
退出登录后Postman仍携带旧Cookie的典型现象
调用退出接口（如 POST /logout）返回200，但紧接着请求用户中心接口仍能成功返回数据；或退出后再登录另一账号，后续请求却仍返回前一个账号的信息——这说明服务端虽清除了Session，但Postman仍在自动发送旧Cookie头。
根本原因不是后端没处理，而是Postman的Cookie Jar默认持续生效，它不关心你“逻辑上已退出”，只机械地按域名+路径规则复用已存Cookie。
验证退出是否真正清除Cookie的三步操作
别依赖响应状态码，重点看请求发出时到底带了什么：
- 在退出请求的
Headers选项卡中，勾选 Show headers，确认请求本身没手动加Cookie头（避免干扰判断） - 退出请求发完后，立即点击右上角
Cookies链接，打开 Cookie Manager，找到对应域名（如api.example.com），检查列表是否为空 —— 若仍有JSESSIONID、PHPSESSID等条目，说明服务端未下发有效的Set-Cookie清除指令 - 手动触发一次新请求（如
GET /user/profile），在请求发出前点开Headers→hidden，看Cookie行是否存在；若存在且值未变，即为失效验证失败
服务端配合退出的Cookie清除关键点
仅返回200不够，必须让浏览器（和Postman）收到明确的过期指令。常见错误写法：Set-Cookie: sessionId=; Max-Age=0 或 Set-Cookie: sessionId=; Expires=Thu, 01 Jan 1970 00:00:00 GMT。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
但实际需严格匹配登录时下发的元数据，否则Postman可能因 Domain、Path 不一致而保留旧Cookie：
- 登录时返回
Set-Cookie: sessionId=abc; Path=/api; Domain=example.com; HttpOnly，退出时就必须用完全相同的Path和Domain发送清除指令 - 若登录Cookie带
Secure，退出响应也必须走HTTPS并带Secure标志，否则Postman会忽略该清除指令 -
HttpOnlyCookie无法被JS删除，必须靠服务端响应头清除；若遗漏此标志，前端调用document.cookie删除无效
Postman侧强制隔离退出状态的临时方案
当后端暂时无法修复清除逻辑，又急需验证退出效果时，可绕过Cookie Jar：
- 在请求 Settings 中开启 Disable cookie jar，彻底禁用自动Cookie管理
- 手动在
Headers中添加Cookie，值设为空字符串（Cookie:）或显式覆盖为无效值（Cookie: sessionId=invalid） - 更干净的做法：使用全新环境（Environment），不导入任何预设变量，且确保该环境域名与原测试域名不同（如从
test.example.com切到tmp.example.com），利用Postman的域名级隔离机制
注意：这些是调试手段，不是长期解法。真实用户退出行为依赖服务端正确下发匹配的清除指令，否则浏览器同样会残留Cookie。
