5月26日Supabase状态码从201改200：你的OAuth代码可能正在"假死"

2026年5月26日，Supabase Management API的OAuth令牌交换端点要换状态码了。不是加功能，不是改字段，只是把201 Created换成200 OK。响应体一模一样，令牌照样发，但你的代码可能从今天开始"假装"失败。

Supabase的官方公告很淡定：主流HTTP库（axios、Fetch API、MCP TypeScript SDK、Vercel AI SDK）都按2XX范围判断成功，该干嘛干嘛。但如果你用的是supabase-management-js这类库，确实可以关掉这篇文章了。

真正要头疼的是另一批人——那些自己手写令牌交换逻辑，代码里躺着if (response.status === 201)的；或者在测试里硬编码assert resp.status_code == 201的；又或者日志过滤器只认201算成功的。5月26号之后，这些代码会把正常的200响应误判为失败，悄无声息地走进错误分支。

这次改动涉及的是POST https://api.supabase.com/v1/oauth/token，第三方集成用它拿授权码换访问令牌，或者刷新过期令牌。标准OAuth 2.1流程：表单编码请求，JSON响应带access_token、refresh_token、token_type、expires_in、scope。

Supabase的解释很直接：OAuth 2.1第3.2.3节明确要求令牌端点返回200，"返回201是不合规的，已经导致部分严格遵循规范的客户端交换令牌失败"。换句话说，之前201让规范党栽跟头，现在改成200，轮到宽松党踩坑。没有双赢选项，Supabase选了站规范这边。

最隐蔽的破坏面有四个。第一是严格相等判断：上面那段resp.status === 201的代码，5月26号后会打印"OAuth token exchange failed 200"并返回{ ok: false }——而Supabase那边其实已经成功签发令牌了。你的用户重新授权，你的系统拒绝保存，两边数据开始脱节。

第二是测试断言。任何硬编码201的单元测试、集成测试都会炸。更麻烦的是，如果你的CI流水线只在发布前跑测试，这个问题会潜伏到生产环境才暴露。

第三是日志和监控。只统计201为成功的仪表盘，5月26号后OAuth成功率会"暴跌"到零，引发不必要的告警和排查。第四是下游重试逻辑：误判为失败后，系统可能自动重试，导致同一授权码被多次交换——虽然Supabase会拒绝重复使用的授权码，但错误日志里会多出一堆"授权码已使用"的噪音。

怎么查？全局搜索你的代码库：=== 201、== 201、status_code == 201、status: 201。重点看OAuth相关的HTTP调用、测试文件、日志过滤规则。改成范围判断>= 200 && < 300，或者直接依赖HTTP库的默认成功检测。

这个改动本身很小，但暴露了一个老问题：HTTP状态码的语义承诺，到底该信到什么程度？信太死，规范更新时你崩；信太松，又可能漏掉真正的错误。Supabase这次选了规范优先，代价是一批"刚刚好够用"的代码要还债。