Postman变量必须统一用小驼峰命名（如baseUrl），避免{{baseurl}}、{{BASE_URL}}等混用导致引用失效；同名变量在不同作用域会引发隐性fallback风险；动态设置时键名须与模板引用逐字符一致。
Postman 变量名一旦混用或随意命名，后续切换环境、协作交接、脚本维护时会频繁出现 {{baseurl}}、{{baseUrl}}、{{BASE_URL}} 三种写法同时存在的情况——这直接导致变量引用失效，且错误难以定位。统一命名不是风格问题，而是避免 ReferenceError: variable is not defined 的底线要求。
为什么必须用小驼峰（camelCase）命名变量
Postman 脚本（JavaScript）本身不校验变量名大小写，但实际运行中：pm.environment.get("apiToken") 和 pm.environment.get("apitoken") 是两个完全不同的键。而团队协作时，不同成员对“token”“Token”“TOKEN”的理解不一致，极易引入隐形 bug。
小驼峰是 Postman 官方文档与主流工程实践默认采用的格式，它天然兼容 JS 语法习惯，也便于在预请求脚本和测试脚本中连贯使用。例如：
-
baseUrl（✅ 推荐）→ 可直接用于{{baseUrl}}/users和pm.environment.get("baseUrl") -
base_url（⚠️ 不推荐）→ 在脚本中需额外记忆下划线，易与 Python 风格混淆 -
BASEURL（❌ 危险）→ 看似“强调常量”，但 JS 中无 const 语义，且与{{baseUrl}}引用不匹配
哪些变量名绝对不能重复定义
同名变量在不同作用域共存时，Postman 按优先级取值：局部变量 > 环境变量 > 全局变量 > 集合变量。但若你在环境 A 中设了 timeoutMs = 5000，又在全局里设了同名 timeoutMs = 3000，切换到环境 A 时看似生效，一旦误删该环境变量，就会静默 fallback 到全局值——这种“隐藏依赖”会让超时行为突然变化，极难排查。
务必遵守以下规则：
- 所有环境变量名必须唯一，不与全局/集合变量重名
- 敏感字段如
authToken、clientSecret必须只存在于环境变量中，禁止出现在全局变量里 - 跨环境一致的配置（如公司名、日志等级）才可放入全局变量，且命名加前缀避免冲突，例如
globalCompanyName
如何快速检查命名一致性
手动翻环境管理界面效率低，且容易遗漏。更可靠的方式是导出环境 JSON 文件后用命令行检查：
jq -r '.values[].key' Dev.json | sort | uniq -d
这条命令能立刻列出 Dev 环境中重复的变量名。再配合：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
grep -E '\{\{[a-zA-Z0-9_]+\}\}' *.json | grep -v 'baseUrl\|authToken' | awk '{print $2}' | sort | uniq -c | sort -nr
可统计集合内所有被引用的变量名频次，识别出拼写不一致的别名（比如 {{userId}} 和 {{user_id}} 同时存在）。
脚本里动态设置变量时的命名陷阱
很多人在 Tests 脚本中这样写：
pm.environment.set("AUTH_TOKEN", responseJson.token);
结果后续在 URL 或 Header 中写 {{auth_token}} 就失败——因为键名大小写/下划线不匹配。正确做法是：脚本中设置的键名，必须与模板中引用的名称**逐字符一致**。
建议始终用变量名常量化处理：
- 定义常量：
const TOKEN_KEY = "authToken"; - 设置：
pm.environment.set(TOKEN_KEY, responseJson.token); - 引用：
{{authToken}}（保持完全一致）
这样既避免手误，也方便全局搜索替换。
变量名不是写一次就完事的事——它会在每个请求 URL、每行脚本、每次环境切换中反复暴露。最常被忽略的点是：**环境变量名一旦确定，就不该再被其他作用域覆盖或弱化语义**。比如 apiVersion 表示接口版本号，那就永远不该在另一个环境里被复用为 apiVersion 指代数据库版本。
