Postman 如何用变量范围隔离测试与生产环境

最稳妥的做法不是在每个请求里来回改域名，而是建立两个键名完全一致的 Postman 环境：Test 保存测试值，Production 保存生产值。请求只写 {{base_url}} 这类变量，发送前通过右上角环境选择器切换；再用一个预请求保护脚本，阻止本应只在测试环境运行的请求误发到生产环境。

官方变量文档：https://learning.postman.com/latest-v-12/docs/use/send-requests/variables/variables

下面以健康检查请求为例完成一套可复用配置。示例地址仅用于说明变量结构，不代表真实服务。

步骤一：先整理变量清单，再决定放在哪个范围

不要打开环境编辑器后才临时想字段。先把会变化的值列出来，并判断它属于“所有请求共用”“随环境变化”“只在单次运行存在”还是“敏感凭据”。

环境专属值不要放在 Global。Global 范围过宽，一旦与环境变量同名，虽然环境变量会覆盖它，但旧值仍可能在别的集合中悄悄生效，排查时很容易看错。

步骤二：创建 Test 环境并录入测试值

1. 在左侧栏点击 Add → Environments；也可以打开右上角环境选择器后点击 Add。
2. 把环境命名为 Test，并选择绿色等容易识别的颜色。
3. 添加 base_url，值填写 https://api-test.example.com。
4. 添加 stage，值填写 test。
5. 需要令牌时，优先让安全变量引用 Postman Vault 中的 secret；不要把真实令牌写进教程、共享表格或版本库。
6. 回到右上角环境选择器，选择 Test 使其成为当前环境。

当前版本的环境变量会自动保存。用于发送请求的是变量的本地值；本地值默认不会同步到 Postman 云端，这一点适合个人凭据，但也意味着换设备或交给云端 Runner 时不能假设它已经存在。

步骤三：创建 Production 环境，键名保持完全一致

新建 Production 环境，推荐使用红色或橙色作为提醒。变量键仍然写 base_url、stage 和 api_token，只替换对应值：

• base_url：https://api.example.com
• stage：production
• api_token：指向生产专用 Vault secret，而不是复制测试令牌

键名一致是隔离方案的关键。这样同一条请求不需要保存“测试版”和“生产版”两个副本，避免其中一个副本漏改路径、参数或认证方式。环境之间只交换值，不交换请求逻辑。

步骤四：请求只引用变量，用选择器切换解析结果

新建请求，把地址写成 {{base_url}}/health。当右上角选择 Test 时，Postman 会把它解析为测试地址；切换到 Production 后，同一个请求会解析为生产地址。

1. 先选中 Test。
2. 把鼠标移到变量上，或打开 Variables 区域，确认 base_url 解析成测试地址。
3. 点击 Send，检查响应状态与响应体中的环境标识。
4. 只有在明确需要生产验证时才切换 Production，并再次检查解析后的完整地址。

如果变量显示未解析，先检查当前是否选中了环境，再检查键名大小写和拼写。不要为了“先跑起来”把真实地址直接覆盖进请求，否则下一次切换环境时，请求仍会绕过变量。

步骤五：加入预请求保护，误选 Production 时立即停止

仅靠颜色提醒还不够。对于清理数据、创建测试订单或批量写入等只允许在测试环境运行的请求，可以在请求或集合的 Pre-request Script 中加入硬保护：

// 读取当前环境标识，只允许此请求在 Test 环境执行。
const stage = pm.environment.get("stage");

// 未选择环境或误选 Production 时立即中止，避免请求继续发送。
if (stage !== "test") {
  throw new Error(`环境保护触发：当前 stage=${stage || "未设置"}`);
}

如果整个集合都属于测试工具，把脚本放在集合级别更省事；如果只有少数请求危险，则只放在对应请求上。保护条件应依赖明确的 stage，不要仅通过域名是否包含某个单词来猜测环境。

还可以补一段必要变量检查，让缺失配置在发送前暴露：

// 检查请求依赖的环境变量，避免带着空地址或空标识继续执行。
["base_url", "stage"].forEach((name) => {
  if (!pm.environment.get(name)) {
    throw new Error(`缺少环境变量：${name}`);
  }
});

步骤六：理解优先级，避免同名变量把结果覆盖掉

Postman 在多个范围出现同名变量时，会使用更窄范围的值。由宽到窄可理解为：Global → Collection → Environment → Data → Local。越靠后的范围优先级越高。

例如 Environment 中的 base_url 是测试地址，但 Runner 的数据文件又提供了同名字段，那么 Data 值会覆盖环境值。脚本里的 pm.variables.get("base_url") 会返回当前可见的最近范围值；若要明确读取当前环境，则使用 pm.environment.get("base_url")。

// 获取当前解析结果：如果存在更窄范围的同名变量，它会覆盖环境值。
const resolvedUrl = pm.variables.get("base_url");

// 明确读取激活环境中的值，适合做环境保护和配置核对。
const environmentUrl = pm.environment.get("base_url");

// 创建仅在当前请求或集合运行期间存在的局部变量，不污染环境配置。
pm.variables.set("request_id", `req-${Date.now()}`);

排查“明明选了 Test，为什么还是另一个地址”时，先搜索所有范围中的同名键，再检查 Runner 数据和脚本是否创建过局部变量。不要只盯着环境编辑器。

敏感值与团队共享要单独处理

环境隔离解决的是“值属于哪个工作上下文”，并不自动解决密钥安全。令牌、密码和客户端密钥应放进 Postman Vault，或至少标记为安全变量并保留在本地值中。直接引用 Vault secret 时可使用 {{vault:api-token}}；如果环境中的安全变量再引用 Vault secret，请求可以继续使用统一的 {{api_token}}。

团队成员收到环境结构后，应在自己的 Vault 或本地值中补齐凭据。云端 Runner 需要使用已共享的 Vault 与已共享变量，不能依赖某台电脑上的本地值。分享前只共享键结构和非敏感默认值，不要把生产令牌当成“方便配置”一起发出去。

完成后的核对清单

• Test 与 Production 的变量键名完全一致。
• 请求地址、认证头和脚本不再写死环境专属值。
• 环境选择器能清楚显示当前环境，生产环境使用醒目颜色。
• 危险请求拥有基于 stage 的预请求保护。
• 没有在 Global 中残留同名的环境专属变量。
• 令牌保存在 Vault 或本地安全值中，没有出现在共享文件和日志里。

常见问题

为什么切换环境后请求地址没有变化？

先确认请求使用的是 {{base_url}}，而不是已经解析后的固定地址；再检查环境是否激活、键名是否一致，以及 Data 或 Local 范围是否存在同名覆盖。

测试和生产可以使用不同变量名吗？

技术上可以，但会迫使请求写条件判断或维护两个副本。使用相同键名、不同环境值，才能真正做到“切换环境而不修改请求”。

为什么同事导入环境后拿不到我的令牌？

本地值默认不向云端同步，Vault secret 也不会自动变成团队公共凭据。这是安全设计。让每位成员在自己的 Vault 中配置令牌，或按团队策略使用共享 Vault。

能否只用 Global 变量区分环境？

不建议。Global 适合真正跨工作区通用的值，环境地址和凭据放在那里会扩大影响范围，也更容易被其他集合意外复用。

最终目标很简单：请求模板保持一份，环境值各自保存，发送前能看清当前目标，危险操作还有脚本兜底。做到这四点，Test 与 Production 才算真正隔离。