Postman同名参数不覆盖而按作用域优先级叠加生效，实际常表现为后定义值胜出；变量优先级为局部>集合>环境>全局；URL重复键名会全部拼入，解析依赖后端配置。
Postman 中同名参数不会自动“覆盖”，而是按作用域优先级叠加生效——但实际效果常表现为后定义的值“胜出”，尤其在环境切换或脚本动态赋值时容易误以为是覆盖。
Postman变量作用域优先级决定谁生效
当多个作用域存在同名变量（如 base_url 同时存在于全局、环境、集合、局部），Postman 按固定顺序取值：局部变量 > 集合变量 > 环境变量 > 全局变量。这个顺序不可更改，也不支持“合并”或“追加”。
- 局部变量只在当前请求的 Pre-request Script 或 Tests 脚本中有效，比如
pm.variables.set("token", "abc123") - 集合变量在集合编辑页的
Variables标签页设置，对整个集合内所有请求生效 - 环境变量通过右上角环境选择器加载，切换环境即切换整套变量值
- 全局变量最宽泛，但一旦被更高优先级的同名变量存在，就完全不参与本次请求解析
URL 查询参数（Params）里重复键名会怎样
在 Params 标签页手动添加多个相同 Key（比如两个 id），Postman 会把它们都拼进 URL，形成类似 ?id=1&id=2 的结构。这取决于后端如何解析——Spring Boot 默认只取第一个，Node.js 的 querystring 默认转成数组，而 Express 需要显式配置 arrayFormat: 'brackets' 才能识别。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 浏览器地址栏或 curl 手动拼接时，重复
key是合法 HTTP 行为，但语义模糊 - Postman 不做去重或报错，也不会警告你加了两个
user_id - 如果后端用
@RequestParam List<string> user_id</string>接收，才可能拿到多个值；否则大概率只收到第一个
脚本中多次 set() 同名变量的实际效果
在 Pre-request Script 里连续调用 pm.environment.set("timeout", "3000") 和 pm.environment.set("timeout", "5000")，最终生效的是最后一次赋值。这不是“覆盖旧值”的原子操作，而是每次写入都直接更新内存中的当前值。
- 局部变量
pm.variables.set()每次调用都会刷新，无历史保留 - 环境/全局变量的
set()会持久化到当前 session，但不会写回环境 JSON 文件，除非你点“Save” - 常见陷阱：在 Tests 里用
pm.environment.set()修改变量，想供下个请求用——它确实生效，但如果你没开启 Collection Runner 的「Persist variables」选项，下次手动点击 Send 时该值可能已丢失
真正容易被忽略的是：变量名大小写不敏感，但团队命名习惯不统一时，ApiToken 和 apitoken 在 Postman 内部会被视为同一个变量，导致意外交互。建议所有变量统一用小写下划线风格，比如 auth_api_key，并写进团队协作规范里。
