Postman获取OAuth令牌后，需在请求或集合的Authorization选项卡中手动设Type为OAuth 2.0并选中已命名的令牌，否则不会自动添加Bearer头；常见401原因包括未保存配置、父级继承覆盖、Scope不匹配或Client Authentication方式错误。
Postman拿到OAuth令牌后，Authorization头怎么自动加？
Postman不会在你点完“Use Token”后就默默把Authorization头塞进每次请求——它只会在你**当前选中的请求或集合**的授权配置里生效，而且必须确认“Type”仍为OAuth 2.0，且Token下拉框中已选中那个刚获取的令牌名。
常见错误现象：401 Unauthorized，但你明明点了“Use Token”。原因往往是：请求没保存、集合层级覆盖了授权设置、或者你误选了“Inherit auth from parent”而父级是No Auth。
- 检查当前请求的
Authorization选项卡 → 确认Type是OAuth 2.0（不是Bearer Token） - 确认
Token下拉菜单中已选中你命名的那个令牌（比如ms-graph-prod），不是空或None - 如果该请求属于某个集合，请右键集合 →
Edit→Authorization→ 关闭Inherit auth from parent，或直接在此处设好OAuth 2.0并选令牌 - 点击右上角
Preview Request，看发出的请求头里是否真有Authorization: Bearer xxx...—— 这是最直接的验证方式
为什么Request Token成功了，但后续请求还是401？
OAuth 2.0令牌本身有效，不代表Postman一定把它用对了。最常被忽略的是作用域（Scope）和客户端认证方式（Client Authentication）不匹配服务端预期。
例如：调用Microsoft Graph API时，若你在获取令牌时填的Scope是https://graph.microsoft.com/User.Read，但请求的是/me/drive，就会因权限不足返回403；又比如服务端强制要求Client Secret必须放在Authorization头（即Send as Basic Auth header），而你选了Send as request body，也会触发401。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 回头检查当初填的
Scope是否覆盖目标API所需的全部权限（多个用空格分隔，不是逗号） - 确认
Client Authentication选项和服务端文档一致：多数云厂商（Azure AD、Auth0、华为帐号）要求Send as Basic Auth header；少数内部系统可能要求Send client credentials in body - 令牌过期后不会自动刷新——Postman不维护
refresh_token生命周期，你得手动点Get New Access Token重拿
能不能不用OAuth 2.0类型，直接粘贴Bearer Token？
能，但不推荐用于调试流程本身。因为Bearer Token类型只是静态填一个字符串，它绕过了Postman对OAuth 2.0协议各环节（比如state校验、PKCE code verifier生成、重定向跳转）的封装和验证能力。
适用场景仅限于：你已经通过其他方式（curl、代码、第三方工具）拿到了有效access_token，只想快速发一两个请求测试响应结构；或者服务端只认Bearer头，根本不走标准OAuth流程（比如某些自研JWT网关）。
- 切换到
Authorization→Type选Bearer Token→ 在Token框里粘贴完整字符串（不含Bearer前缀） - 注意：这种方式下，Postman完全不校验
expires_in，也不会提醒你令牌已过期 - 若需长期维护，建议仍走
OAuth 2.0流程配置，并把Token Name设为带环境标识的名称（如prod-api-token），方便后续切换
多个环境（dev/staging/prod）共用一套OAuth配置，怎么避免混用？
Postman本身不支持“按环境动态切换OAuth参数”，但你可以用变量+集合级授权来模拟。关键点在于：把所有OAuth配置项（Access Token URL、Authorization URL、Client ID等）全换成变量，再在不同环境里赋予不同值。
否则容易出现：在dev环境里点“Request Token”，却向prod的Access Token URL发请求，导致失败或越权。
- 在集合的
Authorization页点Get New Access Token时，所有输入框都填形如{{auth_url}}、{{client_id}}这样的变量 - 在
Environments里分别为dev、staging、prod定义对应变量值（包括scope也要区分） - 确保切换环境后，再点
Request Token——Postman会用当前环境变量值发起请求 - 别忘了在
Manage Tokens里给每个环境的令牌起不同名字（如dev-token-2026），否则容易点错
Grant Type）与服务端实际接受的流程不一致。比如选了Authorization Code，但服务端只支持Client Credentials；或者开发环境开了PKCE但Postman配置里没勾Enable PKCE。这类问题不会报错语法，而是卡在重定向或返回invalid_request，得盯住Postman控制台里的完整请求/响应链才能定位。 
