Postman 环境变量不生效通常是因为未激活环境、变量作用域冲突或语法书写错误。排查时优先确认右上角环境选择器状态，再检查变量名是否匹配，避免在 Pre-request Script 中意外覆盖变量值。
先说结论：变量不生效多为配置选择或作用域优先级问题，需按顺序检查环境激活状态与变量定义位置。
- 先确认：右上角 Environment 下拉框是否选中了对应环境，而非 No Environment。
- 先处理：检查请求中变量语法是否为双花括号 {{variable}} 且无空格，确认变量名大小写一致。
- 再验证：通过 Console 面板查看变量解析后的实际值，或鼠标悬停查看预览。
快速处理思路
Postman 为图形界面工具，排查重点在于界面状态确认与变量预览。
- 查看右上角环境选择器，确保已选中目标环境。
- 点击环境图标（眼睛形状）打开管理页，确认变量 Initial Value 或 Current Value 有值。
- 在请求 URL 或 Body 中，将鼠标悬停在变量上，查看 Tooltip 显示的实际解析值。
为什么会这样
变量不生效的核心原因是 Postman 变量作用域 hierarchy 导致优先级覆盖，或环境未激活导致解析失败。
Postman 变量存在作用域层级，优先级顺序为 Local > Environment > Collection > Global。如果多个作用域定义了同名变量，高优先级会覆盖低优先级。此外，若未选中任何环境，环境变量将被视为未定义，请求中会保留原始 {{variable}} 文本。
分步处理
- 检查环境激活状态：查看 Postman 右上角下拉框，确认当前选中的环境名称。若显示 No Environment，环境变量无法读取。
- 核对变量名称与语法：确认请求中使用的语法为 {{variable_name}}，花括号内无空格。变量名区分大小写，Env_Var 与 env_var 视为不同变量。
- 排查脚本干扰：检查 Pre-request Script 中是否有 pm.environment.set 或 pm.variables.set 语句意外清空或覆盖了该变量。
- 检查 Collection Runner 数据文件：若使用 Runner 运行，确认数据文件 CSV/JSON 中的列名是否与变量名一致，Runner 数据会覆盖环境变量。
怎么验证是否生效
通过 Console 日志与鼠标悬停预览确认变量解析结果。
- Console 面板：点击底部 Console 按钮，发送请求后查看日志，变量会被解析为实际值显示。
- 鼠标悬停：在请求编辑区将鼠标悬停在 {{variable}} 上，Tooltip 会显示 Current Value。
- 测试断言：在 Tests 脚本中添加 console.log(pm.variables.get("variable_name"))，查看输出值是否符合预期。
常见坑
- 花括号空格：写成 {{ var }} 会导致无法识别，必须为 {{var}}。
- 初始值与当前值混淆：环境管理页中 Initial Value 用于同步，Current Value 为本地运行值，排查时以 Current Value 为准。
- 集合级变量干扰：若 Collection 级别定义了同名变量，即使选中环境，也可能因优先级逻辑导致混淆，建议命名时区分环境前缀。
常见问题
全局变量和环境变量有什么区别？
全局变量在所有环境中可用，环境变量仅在当前选中环境中生效。
为什么脚本设置的变量请求中不生效？
脚本设置的变量需确保作用域正确，且未在后续步骤中被覆盖，建议通过 Console 日志确认设置成功。
Collection Runner 运行时报变量缺失怎么办？
检查 Runner 加载的数据文件列名是否与变量名一致，数据文件优先级高于环境变量。
参考来源
- Postman 官方学习中心 - Variables overview: https://learning.postman.com/docs/sending-variables/variables/
- Postman 官方学习中心 - Variable scopes: https://learning.postman.com/docs/sending-variables/variables/variable-scopes/