Postman未认证请求默认不带Token，但可能因Authorization页签、Headers手动添加、环境变量或Pre-request脚本自动注入而误带鉴权头；需按优先级排查并清理。
不带 Token 的请求，Postman 默认就是这么发的——你什么都不用做，它就天然符合“未认证”场景。真正容易出错的，是误加了 Token 却没意识到，或者环境变量/全局变量悄悄注入了认证头。
为什么发出去的请求还是带了 Authorization 头？
Postman 会从多个地方自动注入鉴权信息，优先级从高到低依次是：Authorization 页签设置 → Headers 页签手动添加的 Authorization 或 Cookie → 环境变量/全局变量中定义的 token 变量被脚本引用（比如 Pre-request Script 中写了 pm.request.headers.add(...)）。
常见错误现象：
- 明明没填
Authorization页签，响应却返回200（实际应为401） - 切换环境后，同一个请求在 A 环境报
401，B 环境却成功 - 导出集合再导入，
Tests脚本里有pm.environment.set("token", ...)，但你忘了清空
实操建议：
- 检查
Authorization页签是否为No Auth（不是Bearer Token、API Key等） - 点开
Headers页签，删掉所有含Authorization、X-Token、Cookie的行（哪怕值为空） - 打开
Pre-request Script，搜索add、set、token、auth关键字，确认没有动态插入头 - 临时禁用环境：右上角环境选择器设为
No Environment
如何确保断言能准确验证 401 响应？
只看状态码不够。有些接口在无 Token 时返回 401，但也有返回 403 或 200 + { "code": 401 } 的设计。必须结合响应体和 Header 判断。
实操建议（写在 Tests 页签）：
- 基础校验：
pm.response.to.have.status(401) - 防假阳性：
pm.expect(pm.response.json()).to.not.have.property("data")（假设正常响应必含data字段） - Header 验证：
pm.expect(pm.response.headers.get("WWW-Authenticate")).to.include("Bearer")（标准 OAuth 流程） - 避免硬编码：
const expectedCode = pm.environment.get("expected_unauth_code") || 401;，再用pm.response.code === expectedCode
测试多个无 Token 场景时怎么避免重复操作？
别一个个手动删头。用集合级别的 Pre-request Script 统一清理，再配合不同命名的请求做区分。
例如，在集合根节点的 Pre-request Script 中写：
pm.request.headers.remove("Authorization");
pm.request.headers.remove("X-Auth-Token");
pm.request.headers.remove("Cookie");
这样集合下所有请求默认都不带认证信息。如需个别请求带 Token，再单独在该请求的 Authorization 页签里开启。
性能与兼容性提示：
- 这个脚本执行开销极小，不影响请求耗时
- 适用于 Postman v10.20+；旧版本请改用
pm.request.headers.all().forEach(...)过滤删除 - 如果接口依赖 Cookie 鉴权（如 Session），仅删 Header 不够，还需在
Cookies页签里点击Manage Cookies→Remove All
最容易被忽略的一点：浏览器或系统代理（比如 Fiddler、Charles）可能自动注入 Cookie。如果你在 Postman 里确认已清空所有鉴权项，但响应仍是 200，请先关掉代理重试。
