Postman 怎样保存环境变量并切换请求环境

在 Postman 里同时调本地接口和测试接口时，最稳妥的做法不是反复改请求 URL，而是把地址、令牌等可变内容放进环境变量。这样同一个请求只保留 {{base_url}}/health，切换右上角的活动环境后，实际使用的值就会跟着变化。

官方地址：https://learning.postman.com/docs/use/send-requests/variables/managing-environments/

最小闭环是：创建环境 → 添加变量 → 在请求中用双大括号引用 → 切换环境 → 从变量预览和请求地址两处核对。

一、先创建一套可切换的环境

打开 Postman 工作区后，有两条入口都可以创建环境：点击侧边栏的加号并选择 Environments，或者打开工作区右上角的环境选择器，再点击新增。先创建名为 local 的环境，名称最好直接表达用途，后面再复制出 test。

环境不是一条请求，也不是一个固定地址。它是一组可以被请求、请求脚本和响应脚本引用的变量集合；激活某个环境后，这组变量才会成为当前请求的优先配置。

二、保存变量时分清名称、本地值和共享值

进入 Environments，选择刚创建的 local，添加两个变量：

实际值写入变量编辑器的本地值列即可。Postman 文档说明，环境变量的本地值用于发送请求，默认不会同步到 Postman Cloud；如果团队确实需要一个共享的默认值，再单独决定是否填写或共享 shared value。真实令牌、密码和密钥不要为了“方便协作”直接放到文章、截图或公共集合里。

变量会自动保存，但保存后要看一眼变量行是否仍然存在，并确认变量名没有多余空格。变量名只负责被引用，值才决定请求会发到哪里。

三、切换环境后怎样确认请求真的变了

回到一个请求，把 URL 改成 {{base_url}}/health。需要认证时，把请求头的值写成 {{api_token}}。不要把 local 的真实地址硬编码在请求里，否则切换环境时只有环境名称变了，请求目标并不会变。

复制或新建 test 环境，把它的 base_url 换成测试服务地址，然后在工作区右上角选择 test。验收时按这个顺序看：

1. 右上角环境选择器显示的是 test，而不是 No environment。
2. 打开工作区的 Variables 预览，能看到当前活动环境的本地值。
3. 请求 URL 中的 {{base_url}} 已解析为 test 环境对应的地址，且没有留下黄色未解析变量提示。

这三处能互相对上，才说明切换完成。只看环境下拉框是不够的，因为请求可能仍引用了同名的集合变量或全局变量。

四、变量不生效时按四个方向排查

先看活动环境。如果选择器显示 No environment，环境变量当然不会参与请求；先重新选择目标环境。

再看变量作用域。Postman 会按作用域选择值，局部变量和数据变量可能覆盖环境变量；同名变量很多时，先临时换一个更具体的名字，避免把问题误判成保存失败。

检查本地值与共享值。你在本机发送请求用的是本地值，团队或云端功能使用的值可能不同。敏感变量优先保留本地值，并把共享值当成协作配置而不是秘密存储。

最后检查拼写和引用格式。变量名必须完全一致，引用写成 {{base_url}}，不能漏掉一侧大括号，也不要把 base-url 和 base_url 混用。

五、常见问题

为什么我切换环境后 URL 还是原来的？先确认 URL 里真的使用了 {{base_url}}，再检查是否存在同名的集合变量、全局变量或局部变量覆盖。

环境变量保存后同事看不到怎么办？本地值默认不等于共享值。若只是个人调试，保持本地即可；若要给团队提供非敏感默认配置，再按团队权限共享对应值。

一个请求可以同时使用多个环境变量吗？可以，URL、参数、请求头和请求体都能引用变量，但要让每个变量的职责单一，例如只用 base_url 表示根地址。

总结一下：环境负责分组，变量负责替换，右上角选择器负责切换，Variables 预览和请求 URL 负责验收。把这四件事连起来，Postman 的 local/test 请求就不需要来回手改地址了。