Val Town 又换认证了。
链路很短：Supabase → Clerk → Better Auth。反常点也很清楚：Clerk 并不是一个没人用、做不下去的产品。它刚融了 5000 万美元，也有不少满意用户；Supabase 同样势头很强，刚拿到 1 亿美元融资，估值 50 亿美元。
但 Val Town 还是走了。
这件事最值得看的，不是“Clerk 好不好”。而是认证服务一旦接管用户表和会话，省掉的工程活，很可能换成架构锁死和可靠性债务。对社交、协作、平台型产品来说，这不是边角问题，是地基问题。
Val Town 离开的不是 Clerk，而是一套架构假设
Val Town 原来用 Supabase 的一整套能力，包括认证。2023 年迁出 Supabase 后，它把数据库放到 Render，把认证交给 Clerk。到 2023 年底，团队内部已经开了“离开 Clerk”的 issue。一个月前，这个 issue 关闭，认证切到了 Better Auth。
这条迁移线索可以压成一张表：
| 阶段 | 方案 | 拿到的便利 | 暴露的代价 |
|---|---|---|---|
| 起点 | Supabase | 认证和数据库在同一平台内 | 迁出时耦合明显 |
| 中间 | Clerk | 认证、用户数据、会话都更省心 | 用户表和会话控制权外移 |
| 现在 | Better Auth | 开源核心，本地掌控数据和会话 | 仍有维护方集中带来的 vendor risk |
Clerk 早期有一个很强的主张：可以考虑“删除 users table”。甚至有视频标题叫“DELETE your Users table”。
这对简单前端应用很诱人。用户只看自己的头像、邮箱、设置，JWT 里带一点信息，后台少管很多事。小团队少写很多胶水代码，当然开心。
Val Town 不是这种产品。
它有社交属性。页面上会出现很多别人的用户名、头像、内容归属。用户表不是登录流程的附属品，而是产品骨架。
硬伤很快出现。
Clerk 用户 API 曾经有一个生产限流：整个账户 5 requests/second。不是单用户，是全账户。开发时读取用户名、头像、邮箱很顺；到生产环境，社交列表页就可能撞墙。
Val Town 只能把 Clerk 数据通过 webhook 同步到自己的数据库。同步一上来，中间态也跟着来了：
- 用户已经有 Clerk 账户，但 Val Town 数据库里还没有用户行；
- 用户行有了，但用户名还没补完；
- 认证策略归 Clerk，用户名、编辑器设置等归 Val Town；
- 同一类用户信息开始出现“双权威”。
这不是接口慢一点的问题。状态变多了，边界变糊了，事故路径变长了。
“天下熙熙，皆为利来。”放到 SaaS 里，就是供应商卖的是省心，客户买的是少写代码。但少写的那部分代码，如果正好是你的产品骨架，迟早要还。
真正致命的是会话：外包后变成全站单点
用户表带来的是数据模型冲突。会话托管带来的，是可靠性冲突。
现代 Web 会话常常短周期、持续刷新。好处是可以快速失效。坏处是用户每隔几分钟就要换一次 cookie。Val Town 当时的刷新流程依赖 Clerk。
结果很直接：Clerk 一旦出问题，不只是注册、登录、退出坏掉。已经登录的用户，也可能无法正常使用网站。
这类故障很阴。
它表面上叫“认证服务宕机”，落到产品上就是“全站关键路径断了”。原文提到，从 2025 年 5 月以来，Clerk 状态页显示大致在 two to three nines 之间；更早没有公开数据，Val Town 作者只说自己记得多次网站坏掉且无法修。
这里不能写成“Clerk 普遍失败”。证据不支持。
Clerk 适合不少场景：简单前端应用、后台管理、社交关系弱的产品、想快速接入登录和反滥用能力的小团队。它的 SDK 覆盖 Remix、Fastify、Express，也做了后台管理工具。对这些团队，Clerk 的价值是真的。
Val Town 的问题在另一层：Clerk 的默认架构假设，和 Val Town 的产品形态不合。
做认证选型时，真正该对比的是这几类控制权：
| 控制权 | 可以外包到什么程度 | 失控后的后果 |
|---|---|---|
| 登录入口 | 通常可以外包 | 新用户注册、登录受影响 |
| 用户主表 | 社交、协作、平台型产品要谨慎 | 用户资料、关系、内容归属出现双权威 |
| 会话刷新 | 强依赖外部服务风险很高 | 已登录用户也可能被拖下线 |
| 权限和状态 | 越接近核心业务，越该本地掌控 | 产品逻辑被供应商可用性和模型限制卡住 |
对正在选型认证方案的开发者和 CTO，这意味着动作要变。
如果你做的是内容社区、协作工具、开发者平台，采购 Clerk、Auth0、Supabase Auth 或类似方案前，别只看接入速度。要画一张故障图：供应商 API 慢了、webhook 丢了、会话刷新失败了，哪些页面还能用，哪些数据会变脏。
如果你已经上线，短期未必需要迁移。更现实的动作是补三件事：本地用户表是否是权威源；会话是否能在供应商短时故障时继续有效；用户资料同步失败时有没有可恢复路径。
这比“要不要自研认证”更重要。
Better Auth 赢在边界感，但还没到可以闭眼押注
Val Town 选择 Better Auth，吸引力主要有三点：代码质量不错，框架集成可用，开源核心能独立运行。
更关键的是，Val Town 拿回了两件事：数据和会话。
在 Val Town 的用法里，Better Auth 的付费服务更像无状态辅助。Val Town 管自己的数据，一个插件在自己站点上提供 API，让 Better Auth 的 dashboard 拉取信息，做轻量用户管理。它不再参与会话管理，也不再决定站点是否能维持已登录用户的正常访问。
这就是分水岭。
认证服务不是越省心越好。越靠近用户表、会话、权限和核心状态，越要问：这部分如果外部服务明天挂了，我的网站还像不像一个网站？
当然，Better Auth 也不是神药。原文承认，它是一个大而复杂的代码库，主要由一家公司维护，vendor risk 仍然存在。
只是风险形态变了。
以前的风险是：外部服务不在线，站点关键路径受影响。现在的风险更像：开源项目和维护方长期质量能不能跟上。两者都要管，但不是一个量级。
Val Town 迁移时还做了两周过渡。端点同时接受 Better Auth 和 Clerk 两种 cookie，用户通过新登录页逐步切过去。LLM 辅助了复杂改造，但安全相关代码最后仍然需要逐行读、重写、测试。
机器人能提速，不能替你背锅。
接下来最该观察的变量也不复杂：Better Auth 的维护质量能不能稳住；Val Town 本地会话和用户数据模型能不能减少事故半径；Clerk 这类托管认证服务，会不会把“保留本地用户表”和“弱化会话单点依赖”做成更清晰的产品边界。
Val Town 这次不是在否定 Clerk，而是在提醒一件老事：成功产品也可能带错架构假设。对的人用它，是捷径；错的人用它，是锁链。