Postman不支持在Authorization标签页中自动将API Key作为查询参数注入，因其API Key认证仅支持Header或Query Params两种位置，且Query Params需手动指定Key名并依赖URL现有结构；最稳妥方式是直接在Params标签页填写，或用Pre-request Script动态构造。
Postman 不支持在 Authorization 标签页里直接把 API Key 当作查询参数（query parameter）自动注入——它只会按所选认证类型往 Header、Body 或 URL 中特定位置塞值，而“加到 URL 查询串末尾”不属于任何标准认证类型的默认行为。你得手动处理。
为什么 Authorization 下拉菜单里没有“API Key as Query Param”选项
Postman 的 API Key 认证类型确实存在，但它默认只支持两种位置：Header（如 Authorization: ApiKey xxx）或 Query Params（如 ?api_key=xxx）。但注意：这个“Query Params”选项**不是无脑追加到 URL 后面**，而是严格依赖你填的 Key 字段名——它会把 Key 作为参数名，Value 作为参数值，插入当前 URL 已有的查询参数中（不覆盖、不重复、不排序）。
- 如果你 URL 已带
?v=1，选Query Params并填Key=api_key、Value=abc123，最终发出去的是?v=1&api_key=abc123 - 如果 URL 是纯路径（如
/users），它会自动补上?，变成/users?api_key=abc123 - 但如果你 URL 已含
?api_key=old，Postman 不会覆盖，而是并行出现两个api_key参数（多数服务端只取第一个，后端行为不可控）
手动加 API Key 到查询参数最稳的方式
绕过 Authorization 标签页，直接在 Params 选项卡里填——这是最可控、最透明的做法，尤其适合调试或对接老系统。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 点开请求的
Params标签页 - 在第一行
KEY列输入你的 API 密钥参数名（例如api_key、key、token，具体看文档） - 在对应
VALUE列输入密钥值，或用变量如{{api_key}}（前提是已在环境里定义） - 不用管 Authorization 标签页选什么，甚至可以设成
No Auth，避免干扰 - 发送前点右上角
Preview Request，确认 URL 确实变成了类似https://api.example.com/data?api_key=xxx
用 Pre-request Script 动态拼接 query 参数（进阶场景）
当 API 要求密钥参与签名、或需和其他参数一起做哈希计算时，单纯靠 Params 静态填不够。这时要用脚本控制 URL 构造逻辑。
比如某接口要求 GET /data?api_key=xxx×tamp=1730745600&sign=xxx，其中 sign 是 api_key + timestamp 的 MD5：
const crypto = require('crypto');
const apiKey = pm.environment.get("api_key");
const timestamp = Math.floor(Date.now() / 1000);
const sign = crypto.createHash('md5').update(apiKey + timestamp).digest('hex');
pm.request.url.addQueryParams([
{ key: 'api_key', value: apiKey },
{ key: 'timestamp', value: timestamp },
{ key: 'sign', value: sign }
]);
- 这段脚本在每次发送前运行，确保
sign值实时有效 -
pm.request.url.addQueryParams()是安全追加方式，不会破坏已有参数 - 别在
Tests里写这个——它执行太晚，URL 已发出
真正容易被忽略的点是：很多团队把 API Key 放 query 里，其实是历史包袱或临时方案，这类接口往往没做防重放、没校验 Referer、也没强制 HTTPS。一旦你发现文档写着“api_key 必须放在 URL 中”，最好顺手检查下响应头有没有 Cache-Control: no-store——如果没有，这个密钥可能已经被 CDN 或代理缓存了。
