先分清两类错误：能不能回跳

本站严格遵守 RFC 6749 §4.1.2.3：在 redirect_uri 逐字节匹配成功之前，不存在"回跳"这条出路。

• 你收到 302 且 query 里有 error= → 说明 client_id 与 redirect_uri 都对得上，问题在参数层。
• 你落在本站一张 400 的错误页（没有跳转）→ 说明 client_id 或 redirect_uri 本身有问题。 这时你的接入代码要看的是状态码，不是 Location；只盯 Location 的 SDK 会把这种情况读成"网络异常"。

authorize 阶段

⚠️ authorize 阶段没有 invalid_client：client_id 不存在与"存在但没审核通过/被停用"都回 invalid_request， 而且不回跳 —— 错误回跳本身会变成"探测哪些 client_id 存在"的信号。invalid_client(401) 只在 token / revoke 阶段出现。

token / revoke 阶段（一律 JSON + 状态码）

userinfo 阶段（RFC 6750）

401 + WWW-Authenticate: Bearer error="invalid_token", error_description="..."。 常见三种 error_description，含义完全不同：

• 「令牌无效或已过期」→ 验签失败或超时，正常现象，刷新即可。
• 「令牌已被撤销」→ 用户撤销了授权 / 管理员强制撤销 / 应用被删。必须重新走授权，重试没有用。
• 「该令牌不代表任何用户」→ 你拿 client_credentials 签的机器票去打 userinfo 了。

三条排查顺序（省掉绝大多数工单）

1. 先确认应用状态：status=1 且 audit_status=1 才能签发。自助申请的应用默认是待审核， 这不是 bug —— 没有这一条，"审核"就只是个展示字段，任何人都能自助拿到一个能签票的应用。
2. 再确认 redirect_uri 是否逐字节相同：尾斜杠、端口、大小写都算不同。 本站不做前缀匹配、不忽略尾斜杠、不支持通配 —— 前缀匹配是 OAuth 最经典的账户接管入口。
3. 最后看本站的 OAuth 日志（后台「日志」→ OAuth 协议页签）。 协议层每次调用都记了 endpoint / client_id / grant_type / status / error， 工单里请带上 client_id 和大致时间点。

一个约定：所有协议端点的响应都带 Cache-Control: no-store

令牌与错误响应都不该被中间缓存。如果你在浏览器后退时看到"旧的 code 又出现一次"， 那是你自己的页面缓存了回调结果，与本站无关。