Postman同名变量优先使用局部变量（pm.variables），其次为数据变量、环境变量、集合变量、全局变量；局部变量仅脚本设置且生命周期限于单请求，数据变量仅Collection Runner中生效。
Postman遇到同名变量时，**优先使用局部变量（pm.variables）**，而不是环境或全局变量。这不是“默认选哪个”，而是有明确、固定的解析顺序——它直接决定你看到的值是不是你预期的那个。
Postman变量优先级规则：从高到低依次是
当请求中出现 {{token}} 这类引用，Postman会按以下顺序查找并取第一个匹配的值：
-
pm.variables（局部变量）：仅当前请求生命周期内有效，脚本中用pm.variables.set()设置 -
data变量（数据变量）：来自CSV或JSON数据文件的当前行数据，仅在 Collection Runner 中运行时存在 -
pm.environment（环境变量）：当前激活环境中的变量，如base_url、auth_token -
pm.collectionVariables（集合变量）：仅对该 Collection 内所有请求生效，不随环境切换变化 -
pm.globals（全局变量）：整个工作空间可见，但优先级最低
注意：pm.variables 是唯一一个**无法通过 UI 界面创建**的变量类型，必须靠脚本设置；而 data 变量只在 Collection Runner 执行时注入，手工发送请求时根本不存在。
为什么你写的 {{host}} 没生效？常见踩坑点
你以为设置了环境变量 host = api.dev.example.com，但请求发到了 api.example.com，大概率是下面几种情况之一：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 你在 Pre-request Script 里执行了
pm.variables.set("host", "api.example.com")—— 局部变量直接覆盖了环境变量 - 你正在用 Collection Runner 运行，并传入了
data.json，其中包含"host": "api.example.com"—— 数据变量优先级高于环境变量 - 你误在集合变量里也定义了
host，且该集合被多个环境共用，结果集合变量被意外继承并干扰了环境配置 - 你在 Tests 脚本里调用了
pm.environment.set("host", ...)，但该脚本执行在响应返回之后，对本次请求无效（只影响后续请求）
pm.environment.get() 和 pm.variables.get() 返回值不同怎么办
这是最典型的调试盲区：你打印日志发现两个 API 调用里 pm.environment.get("token") 值一样，但请求实际发出的 header 却不一样。原因往往出在：
- 前一个请求的 Tests 脚本里写了
pm.variables.set("token", response.token)，这个值被带到了下一个请求（即使没切环境） - 你用了 Newman CLI 运行时没指定
-e dev.json，导致环境变量根本没加载，pm.environment.get()返回undefined，但pm.variables或data里恰好有值，于是“悄悄”用了那个 -
pm.variables不会自动清理，同一个 Collection 多次运行后，旧的局部变量可能残留，建议在 Pre-request Script 开头加pm.variables.unset("temp_id")显式清理
真正难的不是记住优先级顺序，而是意识到：Postman 的变量不是静态配置表，而是一套带生命周期和覆盖逻辑的运行时状态系统。一次 pm.variables.set() 调用，可能让后续十几个请求都偏离你 UI 里看到的环境配置。
