400、401、403、422：实用的 API 错误排查流程

如果服务端连请求结构都无法稳定解析，那么优先关注的应该是 400 Bad Request，而不是先去怀疑 token 或权限。损坏的 JSON、错误的 content-type、重复且冲突的参数、非法查询字符串，通常会在真正的认证逻辑运行前就失败。

因此，400 和 401、403 的排查路径应该完全不同。你首先要确认的是：这个请求对于服务端来说是否是可被理解的请求。

1. 还原实际发送的 body 和 headers。
2. 检查 JSON 或 payload 结构是否有效。
3. 检查 query 参数、content-type 和重复值。

这一步通常适合把 HTTP Status Code Explorer 和 JSON Validator 结合起来使用。

401 Unauthorized 往往意味着认证材料本身有问题，例如 token 缺失、过期、issuer 或 audience 不匹配、签名不正确，或者请求经过代理时 header 丢失。403 Forbidden 则更常见于身份已经被接受，但当前用户没有足够的 role、scope、tenant 权限，或不拥有这个资源。

如果不把这两类情况明确分开，团队就会不停地在错误的方向上修复。排查 401 时，先看 token 是否真的到达服务端；排查 403 时，则优先看角色、权限范围和资源归属。

422 Unprocessable Entity 的关键点在于：请求格式通常是合法的，服务端已经成功解析了它，但在字段验证、业务规则、流程约束等更深一层的检查中拒绝了它。这和 400 的结构本身就有问题是两种完全不同的失败边界。

因此，面对 422，你应该优先检查字段错误、必填项、取值范围、枚举限制、字段之间的依赖关系，而不是继续怀疑 JSON 语法。

• 400：请求结构本身就不可靠
• 401：身份未被接受
• 403：身份已接受，但没有权限
• 422：请求可读，但语义或业务规则不成立

把这四类问题分开，能显著减少 API 排障时的误判。