在多环境之间反复切换接口地址、认证令牌或用户凭证时，是不是经常遇到这些糟心事：

• 每次上线前手动改URL，结果漏改一个导致接口404。
• 把生产环境的token粘贴到开发环境，把测试数据库搅得一团糟。

Postman的环境变量功能正是为此而生。它能让你用同一份请求在不同环境中自动套用对应参数，彻底告别手误和漏改。

当你需要在开发、测试、预发布、生产等多套环境中来回穿梭时，环境变量就是那个靠谱的“智能替身”。一句话概括：创建命名清晰的环境，定义一致Key名的变量（如base_url、auth_token），激活后在URL、Headers、Body中用{{key}}引用，还能通过Tests脚本动态更新Current Value。

创建并命名新环境

点击Postman右上角“Environments”旁边的【+】号，直接新建一个空白环境。

输入环境名称

关键一步：输入环境名称，比如dev_api或prod_config。名字要能一眼看出用途，避免“env1”“test”这类模糊叫法——否则切换时你会一头雾水。注意：环境名一旦保存就无法重命名，删了重建是唯一办法。

点“Add”后立刻进入变量编辑页。此时环境虽已创建成功，但变量还需手动填写才能用起来。

添加关键环境变量

在Variables表格里逐行填入Key-Value对：

• 第一行Key写base_url，Value填https://api.dev.example.com。
• 第二行Key写auth_token，Value填Bearer abc123xyz。
• 第三行Key写timeout_ms，Value填5000。

核心原则：所有Key名在不同环境里必须完全一致。比如在prod_config里也得用base_url这个Key，只不过Value换成https://api.prod.example.com。否则切换环境后变量对不上，请求直接给你个404或401，那就彻底尴尬了。

填完别急着关窗口。先确认Current Value列显示的值和Initial Value一致——这说明当前生效的正是你刚输入的内容。如果某行Current Value为空或不对，手动点一下对应单元格再回车一次，强制刷新就能搞定。

激活环境并验证是否生效

第一步：回到Postman主界面右上角，从环境下拉菜单中选中你刚创建的环境名，比如dev_api。

第二步：点击右上角那个“眼睛”图标（Quick Look），弹出面板里展开Environment Variables，确认base_url、auth_token等变量都出现在列表中且值正确无误。

第三步：新建一个GET请求，URL栏直接输入{{base_url}}/health，发送请求。如果返回200，说明变量已成功注入并解析。若报错“Could not get any response”，大概率是环境没选中，或者URL里双花括号拼错了。

在请求中引用环境变量

方法一：URL路径中直接嵌入——比如{{base_url}}/v1/users/{{user_id}}，这里的user_id可以是另一个环境变量，也可以是手动填的数字。

方法二：Headers里设置认证头——Key填Authorization，Value填{{auth_token}}，一步到位解决认证问题。

方法三：Body为x-www-form-urlencoded时，在value栏写{{username}}或{{password}}，轻松处理表单参数。

方法四：Raw JSON Body里写{"token": "{{auth_token}}", "expires_in": {{timeout_ms}}}。注意小细节：数字类型变量不用加引号，字符串才需要加，千万别搞混。

动态更新环境变量（脚本方式）

打开登录请求的Tests标签页，粘贴以下代码：

const res = pm.response.json();
pm.environment.set("session_token", res.data.token);
pm.environment.set("user_role", res.data.role);

发送该登录请求后，响应里的token和role会自动写入当前环境变量。后续所有请求就能直接用{{session_token}}和{{user_role}}了。

值得强调：这一步不会覆盖Initial Value，只改Current Value。所以团队协作时别人拉取你的集合，不会意外拿到你的临时token，安全性有保障。