Authorization头未生效是因Pre-request Script覆盖、环境变量为空或Token误贴Body；需用Console查原始请求头、Tests打印验证，并检查Referer/Host/CSRF crumb等隐式校验头。
Authorization头没生效，Token实际没发出去
Postman里选了Bearer Token，但请求发出后服务器根本没收到Authorization头——这是最常被忽略的“假成功”。常见原因包括：在Pre-request Script里覆盖了认证配置、环境变量中token为空却没报错、或者误把Token粘贴到了Body里而非Authorization面板。
实操建议：
- 打开Postman的
Console（View → Show Postman Console），重发请求，直接查看原始请求头里有没有Authorization: Bearer xxx - 临时在Tests里加一行：
console.log(pm.request.headers.get("Authorization"))，确认值是否为预期 - 如果用了环境变量，检查变量名拼写（比如
auth_tokenvsaccess_token），且变量值不能含前后空格或换行
后端校验Referer或Host头，Postman默认不带或值不符
很多API服务会校验Referer或Host头，尤其当它和前端部署域名强绑定时。Postman默认不发Referer，而浏览器请求会自动带上；这就导致“浏览器能通、Postman 403”或“GET能通、POST 403”（因为POST触发预检，服务端对OPTIONS也校验Referer）。
实操建议：
- 在Postman的Headers标签页手动添加：
Referer→https://your-frontend-domain.com（填真实前端地址） - 若后端校验
Host，也加上：Host→your-api-domain.com（注意不是localhost） - 用cURL对比验证：
curl -H "Referer: https://example.com" -H "Authorization: Bearer xxx" https://api.example.com/xxx，结果一致就锁定是头问题
权限缓存未刷新，Token有效但角色权限已过期
Token本身没过期，签名也通过，但后端权限系统（如基于Redis的缓存）里该用户的权限集还是旧的——比如刚被移除了某个permission_code，但缓存没清，或新权限没同步到网关。此时返回403，错误码可能是PERMISSION_MISMATCH或PERMISSION_NOT_PASS。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
实操建议：
- 查响应体是否含明确权限编码，例如
{"code":"PERMISSION_MISMATCH","message":"no permission 'user:delete'"} - 确认权限数据源：查数据库表
iam_permission是否存在对应权限项，再查Redis中gateway:permissions:{userId}缓存值是否包含该权限 - 调用权限刷新接口（如
POST /v1/refresh/permission），或让运维手动执行redis-cli -n 4 DEL "gateway:permissions:*"
Jenkins等老系统需要CSRF crumb，Postman没自动处理
像Jenkins这类系统，默认开启CSRF防护，所有非GET请求必须携带crumb。Postman不会像浏览器那样自动从/crumbIssuer/api/json获取并注入，所以即使Token正确，也会因缺少Jenkins-Crumb头返回403（错误信息常为No valid crumb was included in the request）。
实操建议：
- 先GET一次
/crumbIssuer/api/json，提取响应中的crumb字段值 - 在后续请求Headers中添加：
Jenkins-Crumb→你拿到的crumb值 - 更稳妥的做法是用Pre-request Script自动获取并设置：
pm.sendRequest("https://jenkins-url/crumbIssuer/api/json", res => { pm.variables.set("crumb", res.json().crumb); });，然后Header里填Jenkins-Crumb: {{crumb}}
真正卡住人的往往不是Token本身，而是Token之外那几个不起眼的请求头、缓存状态或服务端的隐式校验逻辑。每次看到403，先别急着重试，打开Console看原始请求，再比对响应体里的错误码——多数时候，答案就藏在那一行code字段里。
