Postman 缺少必要请求头时直接返回 401/403/400 等错误，需主动识别补全；应查文档、抓包比对、用 cURL 导入，并注意 Content-Type 需手动设置、认证头用环境变量动态管理、Pre-request Script 统一注入非认证头。
缺少必要请求头时，Postman 会直接返回 401、403 或 400 错误，而不是提示“缺哪个头”——必须靠你主动识别和补全。
怎么判断接口到底缺哪些 Header
不能只看错误码。比如 401 Unauthorized 看似是认证问题，但实际可能是 Authorization 缺失，也可能是 Content-Type 没设导致后端解析失败，还可能是自定义头如 X-Api-Key 漏填。
实操建议：
- 先查接口文档里明确标注“必填”的 Header 字段（注意：有些文档写在“全局说明”里，不在单个接口页）
- 用浏览器 DevTools 的 Network 面板抓一个成功请求，点开 Headers 查 Request Headers 全部内容，逐项比对
- 如果只有 cURL 命令，粘贴进 Postman 的 Import 功能，它会自动还原大部分 Header（包括
User-Agent、Accept等隐式头） - 遇到
415 Unsupported Media Type，基本锁定Content-Type没设或值不对（如该用application/json却写了text/plain）
Content-Type 和 Accept 必须手动确认
Postman 默认不自动设置 Content-Type，哪怕你选了 Body → raw → JSON，它也不会帮你加这行头——这是高频踩坑点。
常见组合与对应操作：
-
POST /api/login+ JSON body → 手动加Content-Type: application/json -
POST /api/upload+ form-data → Postman 自动设Content-Type: multipart/form-data; boundary=...，**不要手填**，否则会破坏 boundary - 需要接收 JSON 响应 → 显式加
Accept: application/json（某些网关或旧版 Spring Boot 依赖此头才返回 JSON） - 调用 OpenAPI 3.0+ 接口时，部分服务要求
Accept: application/vnd.api+json，填错就返回 HTML 错误页
带认证的 Header 容易漏掉动态值
像 Authorization: Bearer xxx 或 X-Auth-Token: {{token}} 这类头，不能硬编码；一旦 token 过期，所有后续请求全挂。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
正确做法：
- 登录接口的 Tests 标签里写：
pm.environment.set("token", pm.response.json().token) - 其他接口的 Headers 中填：
Authorization: Bearer {{token}} - 别用全局变量替代环境变量——不同测试环境（test/staging/prod）要隔离 token
- 如果 token 是 JWT，可在 Tests 里加校验逻辑：
pm.test("token not expired", () => { ... })，避免拿过期 token 继续发请求
预请求脚本（Pre-request Script）适合批量注入固定头
当多个接口共用一组非认证类头（如 App-Id、Channel、X-Request-ID），手动填易遗漏且难维护。
推荐用 Pre-request Script 统一注入：
pm.request.headers.add({
key: "App-Id",
value: "7722"
});
pm.request.headers.add({
key: "Channel",
value: pm.environment.get("channel") || "web"
});
这样只要改环境变量 channel，整套请求自动适配；也避免把测试专用头（如 X-Debug: true）误提交到生产环境。
注意：pm.request.headers.add() 不会覆盖已存在的同名头，而是追加——如果接口文档要求唯一 Content-Type，就得先删再加，否则可能触发双头报错。
