Postman中敏感变量必须设为Secret：界面显示为••••••，导出JSON中值为空字符串，脚本仍可正常读取使用；仅环境变量和全局变量支持该属性，集合变量不支持。
Postman里别用明文存密码：Secret变量必须开
Postman默认创建的变量是明文可见的，一旦导出环境文件或共享集合，password、api_token 这类值会直接暴露。解决办法只有一个：所有敏感字段在创建时勾选 “Secret” 复选框。
勾选后：
– 界面中显示为 ••••••，无法复制或查看原始值
– 导出的 .json 环境文件里该字段值为空字符串（""），而非真实内容
– 脚本中仍可通过 pm.environment.get("password") 正常读取并使用
- Secret 变量只对环境变量和全局变量生效，集合变量不支持 Secret 属性
- 不要试图用“命名伪装”绕过，比如叫
temp_key却存生产密钥——别人看脚本一眼就懂 - 团队协作时，务必在文档里注明哪些变量是 Secret，避免新成员误删或重置
Token自动刷新别硬写逻辑：用Pre-request Script + Tests配合
很多用户把 Token 刷新逻辑全塞进一个请求的 Tests 里，结果下次请求没带 Token 就失败。正确做法是把鉴权逻辑下沉到预请求阶段，并用变量标记状态。
例如在登录请求的 Tests 中：
const res = pm.response.json();
if (res.access_token) {
pm.environment.set("access_token", res.access_token);
pm.environment.set("token_expiry", Date.now() + res.expires_in * 1000);
}再在其他请求的 Pre-request Script 中检查有效期：
Sa-Token Java 权限认证框架最佳实践助手——28 条常见错误纠偏、6 个关键决策检查点、14 篇全本地自包含 references，从集成到微服务网关鉴权一步到位。
const expiry = pm.environment.get("token_expiry");
if (!expiry || Date.now() > parseInt(expiry)) {
pm.sendRequest({
url: pm.variables.get("auth_url"),
method: "POST",
body: { refresh_token: pm.environment.get("refresh_token") }
}, (err, res) => {
if (!err && res.code === 200) {
const data = res.json();
pm.environment.set("access_token", data.access_token);
pm.environment.set("token_expiry", Date.now() + data.expires_in * 1000);
}
});
}- 注意：Pre-request Script 中不能 await，必须用
pm.sendRequest回调方式 - 如果刷新失败，当前请求会带着过期 Token 发出去，建议在 Tests 中加
401检查并提示人工介入 - 不要把
refresh_token也设为 Secret 后就不管——它本身有长期有效性，需配合短生命周期的access_token使用
环境文件导出前必须清理：检查变量值是否为空或残留
导出 .postman_environment.json文件给同事或 CI 使用前，最容易忽略的是变量的 “Current Value” 和 “Initial Value” 不一致。比如你调试时手动改过 base_url 的 Current Value，但 Initial Value 还是旧的，别人导入后看到的是 Initial 值，实际运行却用 Current 值，行为不一致。
- 导出前，在 “Manage Environments” 页面逐个点击变量，确认 Current Value 和 Initial Value 一致（除非你明确需要运行时覆盖）
- 删掉所有临时测试用的变量，如
debug_mode、mock_response - 用文本编辑器打开导出的 JSON，搜索
"value": ""或"type": "secret"，确保没有意外包含空敏感字段
CI/CD中禁用全局变量：只允许环境变量注入
在 Jenkins 或 GitHub Actions 里跑 Postman 测试时，有人习惯用 --global-var 注入密钥，这是高危操作。全局变量一旦设置，整个工作空间都可见，后续集合可能意外读取到不该访问的 Token。
正确姿势是：只通过 --environment 指定环境文件，并在 CI 脚本中动态生成该文件：
echo '{
"id": "ci-env",
"name": "CI",
"values": [
{ "key": "base_url", "value": "'"$BASE_URL"'", "enabled": true },
{ "key": "access_token", "value": "'"$API_TOKEN"'", "enabled": true, "type": "secret" }
],
"_postman_variable_scope": "environment"
}' > ci-env.json- CI 环境中永远不要用
pm.globals.set()，也不要在集合里读取全局变量 - Postman CLI（newman）不支持运行时设置 Secret 变量，所以必须提前写进环境 JSON
- 如果要用 Vault 或 AWS Secrets Manager，应在 CI 脚本里先拉取密钥，再拼装环境 JSON，而不是让 Postman 自己去调用
真正难的不是设 Secret 或写脚本，而是每次新增一个环境、交接一个集合、导出一次配置时，都要下意识问一句：“这个变量有没有可能被别人看见？它会不会在某个我没注意到的地方被复用？” 变量管理的边界感，比语法重要得多。
