Postman多账号切换需定向清除+显式覆盖+域隔离：清空Cookies面板不等于切换账号，因Cookie按Domain/Path等元数据绑定且可能被预请求脚本或Interceptor隐性污染；应先清目标域名Cookie，再登录获取新Session，最后检查Cookies面板、环境变量和Interceptor同步状态。
Postman 本身不支持“多账号会话”标签页级隔离，所谓“切换账号”，本质是手动控制 Cookie 的归属域和生命周期——否则你发的请求永远带着上一个账号留下的 SessionID。
为什么清空 Cookies 面板里的内容 ≠ 切换账号
很多人点开 Cookies 面板，全选删掉，以为这就干净了。但问题在于：
- Postman 的 Cookie 存储是按
Domain+Path+Secure/HttpOnly等元数据绑定的，不是简单键值对；删掉面板里显示的条目，不代表清除了所有上下文（比如预请求脚本中硬编码的Cookie头） - 如果你在多个 Tab 中分别发过请求，每个 Tab 可能已缓存了不同域名的 Cookie，而
Cookies面板默认只显示当前请求关联的域名；你删的只是“眼前这个”，不是“全部” - 环境变量里若存了旧的
session_id，且在 Pre-request Script 中又被拼进 Header，那删面板毫无意义
真正有效的账号切换三步法
不是“删”，而是“定向清除 + 显式覆盖 + 域隔离”：
- 先确认你要切换的目标域名，比如从
test-api.example.com切到staging-api.example.com，这两个在 Postman 里是完全独立的 Cookie 存储空间，互不影响 - 打开目标域名的任意一个请求 → 点右上角
Cookies→ 在搜索框输入该域名（如staging-api.example.com）→ 点击右侧垃圾桶图标清空该域下所有 Cookie - 再执行一次登录请求（或用预请求脚本注入新 Cookie），确保响应头中的
Set-Cookie被 Postman 正确解析并存入该域名空间；后续同域请求才会自动带上它
Pre-request Script 中伪造多账号 Cookie 的坑
有人写脚本直接塞字符串：pm.request.headers.add({ key: 'Cookie', value: 'JSESSIONID=abc123; user_id=999' })，这看似快，但极易失败：
- 如果服务端设置了
Domain=api.example.com，而你请求的是staging-api.example.com，浏览器/Postman 会拒绝发送该 Cookie（协议层面拦截） - 没处理
Path匹配时，比如服务端设了Path=/v2，而你请求的是/v1/user，Cookie 就不会被带上 - 硬编码值无法应对动态生成的
Expires或Max-Age，过期后请求静默失效，连错误都不报 - 正确做法是：用
pm.cookies.set()显式指定域名和路径，例如：pm.cookies.set("JSESSIONID", "def456", { domain: "staging-api.example.com", path: "/" })
最常被忽略的隐性污染源：Interceptor 同步
如果你装了 Postman Interceptor 并开启了 Sync Cookies，那 Postman 会实时从 Chrome 拉取当前标签页的 Cookie ——哪怕你在 Postman 里删光了，只要 Chrome 里还开着测试账号的页面，它下一秒就又同步回来。解决方法只有两个：
- 临时关闭 Interceptor 的
Sync Cookies开关（右上角插件图标 → 关闭同步） - 或者，在 Chrome 中彻底退出对应账号（不是关标签页，是登出），再清空 Chrome 的
Application → Cookies里对应域名的全部条目
跨账号测试的关键不在“怎么加”，而在“怎么确保旧的不混进来”。每一次切换，都要检查三个地方：Cookies 面板里目标域名是否为空、环境变量里有没有残留 token、Interceptor 是否静默接管。少查一处，就可能白测半小时。
