Postman环境变量分层管理测试地址与令牌的做法

Postman 里测试地址、令牌和临时参数经常同时变化，全部塞进 Global 变量很快就会出现“切了环境但请求还打到旧地址”的问题。更稳妥的做法是按变化范围分层：集合变量放稳定的请求骨架，环境变量放 test、staging 等环境差异，局部变量只存本次请求或运行中的临时值。下面用一个订单接口说明完整操作和验收方法。

官方文档：https://learning.postman.com/docs/use/send-requests/variables/variables

先把地址、令牌和临时值放到不同作用域

先建立一条简单规则：跨多个请求都不变的名称放集合层，例如 api_version；只随 test 或 staging 改变的值放环境层，例如 base_url 和 auth_token；只在一次脚本或运行中使用的值放局部层，例如 request_id。Postman 的变量优先级从宽到窄通常是 global、collection、environment、data、local，窄作用域会覆盖同名的宽作用域。

操作路径：左侧 Environments → 新建 test；再打开目标集合 → Variables。在集合层只保留真正稳定的字段，在环境层填写本地值。局部值不需要长期保存，脚本中可以用 pm.variables 读取。

图中是原创操作示意图，不是真实软件截图。继续前先确认右上角环境选择器显示 test，变量表中能区分共享值和本地值。

创建 test 环境并填写本地令牌

第1步：新建环境。点击右上角环境选择器，选择创建环境；也可以走左侧 Environments → Add。名称填写 test，新增 base_url 和 auth_token 两行。

第2步：填 Local value。base_url 写测试服务地址，auth_token 写当前测试令牌。只填本地值即可满足本机发送；不要把生产令牌放在集合的共享值列。保存后把 test 设为 active environment，右上角应显示当前环境名称。

第3步：核对生效状态。点击请求编辑器中的变量入口，或悬停 {{base_url}}，确认提示来源为 test。若提示为空，先检查当前环境是否激活，再检查填写的是 Local value 而不是仅填写了描述。

在请求中引用变量并验收结果

第4步：填写请求。打开集合中的请求，URL 写成 {{base_url}}/v1/orders；在 Authorization 选择 Bearer Token，令牌输入 {{auth_token}}，点击 Send。不要把真实令牌直接粘进 URL 或正文。

第5步：看两个确认点。发送前，悬停 {{base_url}} 应显示 test 环境来源；发送后，在 Response 面板看接口返回的状态码和正文。示例中的 200 OK 只表示接口成功响应，不能单独证明令牌来自正确环境，因此两个确认点都要看。

若要在脚本里核对最终解析值，可以使用下面的最小示例。它只读取值并打印变量是否存在，不输出令牌本身：

// 只确认变量是否可用，避免把令牌写入 Postman Console
const baseUrl = pm.variables.get('base_url');
const token = pm.variables.get('auth_token');
console.log({
  baseUrlPresent: Boolean(baseUrl),
  tokenPresent: Boolean(token)
});

切换环境后的归档检查

测试通过后，把集合保留为可复用的请求模板；不要把一次性的 request_id 固定写入集合。切到 staging 时只替换 active environment，再重复“悬停变量 → Send → 看响应”的检查。这样能把地址、令牌和临时值的生命周期分开，排查问题时也更容易定位。

常见问题

base_url 应该放集合变量还是环境变量？

只有一个服务地址时可放集合层；test、staging、production 地址不同，就放各环境层，让同一请求通过切换环境复用。

为什么填了变量却显示 unresolved？

通常是环境未激活、变量名拼写不同，或只填写了不可用于当前发送的列。先确认右上角环境，再检查变量名和本地值。

能不能把令牌放 Global 变量？

不建议。Global 作用范围最大，容易被其他集合误用；令牌应尽量限制在当前环境，并避免同步真实秘密。