Postman不自动区分环境认证，需手动创建dev/prod等环境变量并切换使用；Authorization Tab仅识别Collection/全局变量，推荐用Pre-request Script动态构造头并校验空值。
Postman 本身不“自动”区分测试环境和正式环境的认证——它只按你当前选中的环境变量来填充值。关键在于你怎么组织变量、在哪一层（Collection / Folder / Request）设置认证，以及是否用脚本动态生成敏感头。
怎么在Postman里创建并切换测试/正式环境
环境变量是分离认证的核心载体，不是可选项，而是必须项。
- 点击右上角环境图标 → Manage Environments → Add
- 创建两个环境：比如
dev和prod，各自定义独立变量：api_key、username、password、base_url等 - 变量的 Initial Value 可为空或填占位符（如
dev-api-key-here），Current Value 才是实际生效值 —— 切换环境时，Postman 读的是 Current Value - 发送请求前，务必在右上角下拉菜单中手动选择对应环境，否则所有
{{xxx}}都会解析失败或取错值
Authorization Tab 里填变量为什么有时不生效
Postman 的 Authorization Tab 支持变量，但有隐藏限制：它只认 Collection 或更高层级（全局）定义的变量，且不能在 Pre-request Script 中覆盖已由 Tab 自动生成的头。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 如果在 Authorization Tab 里设了
Type: API Key，Key: X-API-Key，Value: {{api_key}}，但请求发出去后头没出现，大概率是{{api_key}}在当前环境里不存在或 Current Value 为空 - Basic Auth 同理：若
Username: {{username}}解析为空，Postman 不会报错，而是发一个空的Authorization: Basic头，服务器直接 401 - 更稳妥的做法是：把 Authorization Tab 设为
No Auth，改用 Pre-request Script 手动构造头，这样你能加日志、做判空、拼接签名等
Pre-request Script 动态生成认证头的实操要点
脚本方式最灵活，也最容易踩坑。重点不是“能不能写”，而是“写在哪”和“取哪个值”。
- 脚本要放在 Collection 级别 的 Pre-request Script 中（而非单个请求），才能让所有子请求共享逻辑
- 取变量统一用
pm.environment.get('xxx')，不要混用pm.variables.get()（那是全局变量，跨环境不隔离） - Basic Auth 示例（带防空保护）：
const user = pm.environment.get('username');
const pass = pm.environment.get('password');
if (!user || !pass) {
console.error('Missing username or password in current environment');
throw new Error('Auth config incomplete');
}
const auth = btoa(`${user}:${pass}`);
pm.request.headers.upsert({ key: 'Authorization', value: `Basic ${auth}` });
- API Key 带时间戳签名示例（避免硬编码）：
const key = pm.environment.get('api_key');
const ts = Date.now().toString();
const signature = CryptoJS.HmacSHA256(`${key}${ts}`, pm.environment.get('secret')).toString();
pm.request.headers.upsert({ key: 'X-API-Key', value: key });
pm.request.headers.upsert({ key: 'X-Timestamp', value: ts });
pm.request.headers.upsert({ key: 'X-Signature', value: signature });
- 注意：CryptoJS 默认可用；若提示未定义，需在 Settings → General → Enable JavaScript sandbox 打开（v10.20+ 默认开启）
Portman 自动生成多环境认证配置的关键点
如果你用 OpenAPI + Portman 生成 Postman 集合，认证配置不是靠手动填，而是靠 JSON 配置驱动。这时变量名必须和 OpenAPI spec 中的 securitySchemes 名称严格一致。
- 例如 OpenAPI 定义了
components.securitySchemes.apiKey，Portman 配置里就要写"apiKey": { "in": "header", "name": "X-API-Key", "value": "{{api_key}}" } - Portman 的
valueReplacements是字符串级替换，只作用于原始 OpenAPI 文档里的占位符（如<api key></api>），不会影响脚本或环境变量逻辑 - 生成后，仍需人工补全环境变量的 Current Value —— Portman 不会往 Postman 环境里写入真实密钥，这是安全设计，不是遗漏
- 不同环境用不同 Portman 配置文件？没必要。一个配置 + 多套环境变量，就能覆盖 dev/staging/prod
真正容易被忽略的，是环境变量的 Current Value 没同步更新，或者脚本里用了 pm.variables.get() 误取全局值。认证失败时，先看 Console 输出，再检查当前环境右上角是否真的选对了，最后确认那个 {{xxx}} 变量在该环境下有没有填 Current Value —— 90% 的问题卡在这三步里。
