Postman的Authorization标签页实际生成并插入请求头中的Authorization字段：Bearer Token→“Authorization: Bearer ”，Basic Auth→“Authorization: Basic ”，Digest Auth生成含realm、response等的完整Digest字符串；手动在Headers中添加同名字段会导致重复，服务端可能取错值。
Postman里Authorization设置到底改了什么Header
Postman的Authorization标签不是“魔法开关”，它只是按规则自动生成并插入某个Header字段。你填的Token、用户名密码，最终都会变成某一行Key: Value出现在请求头里。不确认这行在哪，就等于没确认认证是否真正发出。
常见误区是只看Authorization标签页填对了，却没检查Headers选项卡里是否真有对应条目——尤其当手动添加过同名Header时，Postman可能不会覆盖，而是保留两个Authorization字段，导致服务端取错值。
- Bearer Token → 自动生成
Authorization: Bearer - Basic Auth → 自动生成
Authorization: Basic - Digest Auth → 生成完整Digest字符串，包含
username、realm、response等字段 - 如果手动在
Headers里加了Authorization，Postman默认不会禁用Auth标签页逻辑，两个Header会同时发送（多数服务端只读第一个，但行为未定义）
如何一眼看出认证参数是否被正确拼进URL或Body
有些接口不走Header，而是把Token塞进Query参数（如?access_token=xxx）或Body字段（如{"token":"xxx"}）。这种情况下，Authorization标签页完全无效——它只管Header，不管URL和Body。
必须靠Pre-request Script手动拼接，且要严格匹配服务端约定的字段名（比如auth_token、api_key、甚至X-Auth这种非标准名）。
- 查文档确认认证参数位置：是
Header、Query还是Body？字段名拼写是否含下划线/大小写？ - 在
Params选项卡里找Query参数，注意Encoded开关是否开启（影响空格、中文等编码） - 在
Body选项卡里确认格式：rawJSON需手动写入字段；form-data或x-www-form-urlencoded需在KEY列填准确名 - 用
console.log(pm.request)在Pre-request Script里打印整个请求对象，直接看url.query或request.body内容
为什么Preview Request看到的Header和实际发出去的不一样
Preview Request按钮显示的是“当前配置下将要发送的内容”，但它不执行Pre-request Script。如果你的Token是从环境变量读取、或需要动态计算签名，Preview里看到的仍是原始占位符（如{{token}}），而真实请求中已被脚本替换。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
真正可信的检查方式只有两个：一是用抓包工具（如Wireshark、Charles）看真实HTTP流；二是打开Postman的Console（View → Show Postman Console），点Send后立刻查看日志里记录的完整请求头与体。
-
Console里能看到最终发出的Authorization值，包括Base64解码后的Basic Auth明文（调试时注意隐私） - 如果用了
pm.environment.set()在脚本里改Token，Preview永远看不到更新结果 - 某些加密签名逻辑依赖时间戳或随机串，
Preview无法模拟实时生成过程
Header里出现两个Authorization字段怎么排查
这是最隐蔽也最常导致401的配置冲突。Postman不会报错，但服务端解析时可能取错字段、或因Header格式非法直接拒收。
根本原因通常是：你在Authorization标签页选了Bearer Token，又在Headers选项卡手动加了一行Authorization（哪怕值为空）。
- 检查
Headers选项卡，删掉所有手动添加的Authorization行（哪怕写着key: Authorization、value为空） - 确认环境变量里没有
Authorization变量（比如{{Authorization}}被误用在Header值里） - 在
Pre-request Script中搜索addHeader("Authorization"或headers["Authorization"]，避免脚本重复注入 - 用
Console查看原始请求，搜索Authorization:出现次数，超过一次即为异常
真实联调中，90%的“认证失败”不是密钥错了，而是参数根本没送到该去的地方。盯住Console输出，比反复检查文档更可靠。
