最常见原因是Authorization头格式错误。包括冒号位置错、误用API-Key头、Key含空格或中文引号、缺Content-Type，以及Postman Auth选项卡自动生成不兼容部分平台。
Authorization头格式写错是最常见原因
Postman里API Key明明是对的，但服务端返回401 Unauthorized或"Api key is invalid"，八成是Authorization头没按规范写。不同厂商要求差异很大，不能凭经验硬套。
常见错误包括：
-
Authorization: Bearer your_key_here写成Bearer: your_key_here（冒号位置错） - 用
API-Key: xxx或X-API-Key: xxx，但服务端只认Authorization头 - Key前面多空格、后面带换行、混入中文引号（如
"sk-xxx"里的引号是全角） - 忘记加
Content-Type: application/json，某些API会因此跳过鉴权逻辑
建议直接在Headers里手动输入，不要依赖Postman的Auth选项卡自动生成——它默认选Bearer Token，但DeepSeek、天地图等平台根本不吃这套。
环境变量没生效或被覆盖
你写了{{api_key}}，但实际发出去的请求头里是空的，问题往往出在作用域和激活状态上。
检查步骤：
- 右上角环境选择器是否选中了你配置
api_key的那个环境（不是No Environment） - 在Tests脚本里加
console.log(pm.environment.get("api_key"))，看输出是不是null - 确认没有同名的全局变量（
pm.globals.set("api_key", ...)）把环境变量盖掉了 - 变量名别含短横线或中文，比如
my-api-key在Postman里会被解析失败，改用my_api_key
特别注意：Postman v10.15+对变量嵌套支持更严格，{{base_url}}/v1{{endpoint}}这种写法如果endpoint未定义，整个URL会变成/v1undefined，但错误不报在Auth上，容易误判。
Key类型不匹配：浏览器端AK vs 服务端AK
像天地图这类平台，会明确区分“浏览器端密钥”和“服务端密钥”。Postman哪怕装在Chrome里，运行时也是服务端上下文，用浏览器AK必然报"key权限为浏览器端,请使用浏览器访问"。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
验证方法：
- 打开厂商控制台，看AK详情页有没有“调用来源”或“授权类型”字段
- 对比文档——天地图要求服务端AK必须带
server标识，高德地图叫web-services，百度地图叫server类型SK - curl命令直连测试：
curl -H "X-API-Key: your_server_ak" https://api.tianditu.gov.cn/geocoder，绕过Postman排除UI干扰
这类问题不会报401，而是返回带code: 12的JSON，错误信息里明说“权限类型错误”，但新手常忽略这个提示，反复检查Key本身。
请求头长度或特殊字符触发服务端拦截
某些WebAPI对Header值有硬性限制，比如value超2048字符直接拒收，或遇到/、中文、emoji就静默丢弃键值对。
典型表现：
- Postman里Headers显示正常，但抓包发现实际没发出去（可用Wireshark或Fiddler验证）
- 后端日志里根本没记录这次请求，像是被网关层过滤了
- 把
X-Timestamp设成{{$timestamp}}结果发出去是空的——因为Postman预请求脚本生成的时间戳含:和T，部分老旧服务端解析失败
临时对策：把长Key拆成两段拼接，或改用pm.variables.replaceIn()做安全编码；长期方案是联系厂商确认Header白名单规则，别自己猜。
真正卡住的时候，别只盯着Key对不对——先抓包看发出去的到底是什么，再比对文档里“认证方式”章节的精确描述。服务端不会说谎，但它的错误提示经常藏在响应体JSON里，而不是状态码里。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
