Bearer Token在Swagger可用，Postman登录后调用API却显示无效

• 请求头格式不规范：Postman设置Authorization头时，可能未严格遵循Bearer <token>的格式要求——比如多打了空格、漏加空格，或者把Bearer拼写成小写/错误变体（部分严格的服务会校验大小写）。Swagger会自动生成标准格式的请求头，因此能正常通过认证。
• 环境变量引用错误：如果Postman用环境变量存储Token，可能存在变量名拼写错误、未正确赋值，或者引用语法错误（比如用{{token}}但实际变量名为access_token）。可以直接将Swagger中可用的Token手动粘贴到Postman请求头测试，排除变量问题。
• Postman缓存残留：Postman可能缓存了旧Token或请求头配置，导致实际发送的是过期无效的Token。尝试新建空白请求并手动输入正确Token测试，或在Postman设置中清除缓存。
• 本地与服务器时间差过大：Token有效期基于服务器时间校验，若Postman所在设备的系统时间与服务器时间偏差较大（比如快了数小时），服务器会判定Token已过期。而Swagger运行在浏览器中，时间通常与服务器同步性更好。检查本地设备时间，确保与服务器时区、时间一致。
• 请求环境不匹配：虽然使用同一Token，但Postman可能发送请求到了与Swagger不同的环境（比如Swagger连测试环境，Postman连生产环境，两个环境的Token不通用）。对比两者的请求URL，确认域名、端口完全一致。
• Token携带多余字符：从登录接口复制Token到Postman时，可能误带了JSON返回中的引号、换行符或空格（比如把"abc123"整个复制，而非纯abc123）。Swagger会自动提取纯Token字符串，而Postman若直接使用带多余字符的内容，会导致Token无效。
• 认证方式配置错误：若使用Postman的Authorization标签页选择Bearer Token，可能未正确填写Token字段；或误选了其他认证方式（比如Basic Auth），导致实际发送的请求头不符合要求。建议直接在Headers标签手动添加Authorization: Bearer <token>，避免自动配置的问题。

内容的提问来源于stack exchange，提问作者Irfan Pathan