Postman通过环境变量隔离不同测试账号的Token，而非切换账号；每个账号对应独立环境（如admin-env），在Pre-request Script中按URL判断注入Token，登录接口不带Token，并在Tests中用refresh_token自动刷新过期Token。
Postman里不能直接“切换账号”，但能隔离Token数据
Postman本身没有用户账号切换机制——它不管理你的业务系统账号（比如 admin / testuser01 / guest），只管理你本地的环境变量、集合和请求。所谓“不同测试账号使用各自的Token”，本质是让每个账号的认证凭据（access_token、refresh_token、user_id等）不互相覆盖，且在对应请求中自动注入。这靠的是变量作用域 + 脚本控制，不是登录登出。
用环境（Environment）做账号级隔离，而不是用“账号”
把每个测试账号当成一个独立环境来建：比如 admin-env、buyer-env、seller-env。每个环境文件里存它专属的 Token 和上下文：
-
access_token：从各自登录接口提取，写入对应环境，不写进全局变量 -
user_id、tenant_id等上下文字段也按账号区分，避免误用 - 环境名必须明确可识别，别用
env1、test这类模糊命名 - 不要把多个账号的 Token 都塞进同一个环境——这是最常踩的坑，会导致后续请求发错身份
示例 admin-env.json 片段：
{
"values": [
{ "key": "access_token", "value": "eyJhbGciOi...", "enabled": true },
{ "key": "user_id", "value": "1001", "enabled": true }
]
}
Pre-request Script 中动态注入 Token，且避开登录接口自身
登录接口不能带 Token 发送，否则可能被鉴权中间件拦截或返回 401。所以要在集合层级的 Pre-request Script 里加判断逻辑：
- 检查当前请求 URL 是否包含
/login或/auth关键字 - 如果不是登录请求，再从当前选中的环境里取
access_token注入 Header - 务必用
pm.environment.get()，不是pm.globals.get()，否则跨环境污染
脚本示例：
if (!pm.request.url.toString().includes("/login")) {
const token = pm.environment.get("access_token");
if (token) {
pm.request.headers.add({ key: "Authorization", value: `Bearer ${token}` });
}
}
测试账号 Token 过期时自动刷新，避免手动重跑登录
真实场景中，Token 会过期，但你不想每次失效都手动点一遍登录请求。可以在登录接口的 Tests 里加刷新逻辑：
- 收到 401 响应时，触发刷新请求（调用
/refresh接口） - 刷新成功后，把新
access_token写回当前环境，不是全局 - 用
pm.setNextRequest()重试原请求，形成闭环 - 注意：刷新接口本身不能依赖旧 Token —— 它通常靠
refresh_token或 Cookie 维持会话
关键代码片段：
if (pm.response.code === 401) {
const refreshToken = pm.environment.get("refresh_token");
pm.sendRequest({
url: pm.variables.get("refresh_url"),
method: "POST",
body: { refresh_token: refreshToken }
}, (err, res) => {
if (!err && res.code === 200) {
const newToken = res.json().access_token;
pm.environment.set("access_token", newToken); // ← 写入当前环境
pm.setNextRequest(pm.info.requestName);
}
});
}
真正容易被忽略的是：刷新逻辑必须绑定到具体环境，且 refresh_url 和 refresh_token 也要按账号单独配置——混用会导致 admin 的 refresh_token 被 buyer 请求误刷，引发权限越界。
