在 Web 应用开发中，身份认证是一个看似基础却极其关键的基础设施组件。近期，Val Town 团队发表了他们的认证迁移经历 —— 从 Supabase Auth 到 Clerk，再到 Better Auth。这一路走来的经验教训，对于正在考虑认证方案选型的团队具有重要的参考价值。本文将深入分析这三种认证方案的技术差异与工程权衡，帮助你在实际项目中做出更明智的决策。
迁移背景与时间线
Val Town 的认证演进历程反映了整个行业对身份认证方案的认知变化。2023 年初期，团队从 Supabase 全家桶中迁移出来，将数据库迁移到 Render，认证则切换到 Clerk。这一决策在当时看来是合理的：Clerk 提供了完善的 SDK、多框架支持以及开箱即用的管理后台。然而，仅仅一年后的 2023 年底，团队就提出了 “远离 Clerk” 的需求，直到 2026 年 4 月才最终切换到 Better Auth 并关闭了这个问题。
值得注意的是，Clerk 和 Supabase 都是非常成功的商业产品。Clerk 近期完成了 5000 万美元的 C 轮融资，Supabase 更是获得了 1 亿美元融资，估值达到 50 亿美元。这些商业成功证明了市场对这些产品的广泛认可，但这并不意味着它们适合所有场景。Val Town 的经历恰恰说明了这一点：在特定的技术架构和业务需求下，这些 “成功” 的产品可能会成为系统稳定性的瓶颈。
Clerk 的核心问题：架构冲突
理解 Clerk 问题的本质，需要从其核心设计理念说起。Clerk 从一开始就倡导 “丢弃你的 users 表” 这一概念，官方博客甚至有文章标题为《考虑放弃你的 users 表》，视频教程名为《删除你的 Users 表》。这种设计的出发点是让开发者完全依赖 Clerk 作为用户数据的权威来源，从而简化开发流程。然而，这种设计在社交属性较强的应用中暴露出严重问题。
第一个重大问题是 API 速率限制。Val Town 团队在开发环境中使用 Clerk 的rootAuthLoader的loadUser选项来加载用户数据，一切正常。然而在生产环境中，他们发现 Clerk 对用户端点的速率限制仅为每秒 5 次请求，而且这是针对整个账户、所有用户聚合的限制。对于一个社交平台来说，这是致命的 —— 用户个人资料页、评论列表、动态信息流都需要加载大量其他用户的信息，5 次 / 秒的速率限制远远无法满足需求。这个问题是在生产环境中才被发现，团队最终通过移除该选项并改为同步策略来解决。
第二个问题是单点故障。Clerk 接管了用户的会话管理，用户的 session cookie 需要定期刷新，这意味着每次会话续期都需要经过 Clerk 的服务。当 Clerk 出现宕机时，不仅登录和登出功能不可用，连已登录用户也会因为无法刷新会话而无法使用网站。从 2025 年 5 月开始，Clerk 的服务可用性一直在 99% 到 99.9% 之间徘徊，对于一个需要高可用的生产系统来说，这种不确定性带来的风险是难以接受的。
此外，由于 Clerk 不提供 users 表的概念，团队需要通过 webhook 将用户数据同步到自己的数据库。这导致了一个尴尬的过渡状态：新注册用户在某一时刻只有 Clerk 账户却没有数据库记录，或者拥有数据库记录却因缺少用户名等必填字段而处于不完整状态。用户设置也被迫分散在两处 ——Clerk 控制认证策略，本地数据库存储用户名、编辑器设置等业务相关配置。
三种方案的工程权衡
从技术实现角度来看，Supabase Auth、Clerk 和 Better Auth 代表了三种不同的认证架构模式，每种都有其明确的适用场景和明显的局限性。
Supabase Auth 的优势在于与 Supabase 数据库的深度整合。如果你的项目已经使用 Supabase 作为后端数据库，使用 Supabase Auth 可以减少额外集成的复杂性。它支持行级安全策略（RLS），能够与数据库权限系统紧密配合。然而，当你需要从 Supabase 迁移到其他数据库解决方案时，认证数据的迁移就变得棘手。Supabase Auth 的用户 ID 与数据库中的用户记录紧密耦合，迁移过程需要小心处理 ID 映射关系。
Clerk 的定位是为 “简单的前端应用” 提供无后端负担的认证解决方案。如果你开发的是一个用户主要与自身数据交互的 SaaS 应用，不需要展示其他用户的信息，Clerk 确实能够极大降低开发成本。它提供的管理后台、反垃圾保护、多框架 SDK 都是开箱即用的。但正如 Val Town 的经验所示，一旦你的应用具有社交属性、需要展示其他用户的信息，或者对系统可用性有较高要求，Clerk 的这些 “优点” 就会变成制约因素。
Better Auth 作为开源方案，提供了介于 “自建认证” 和 “完全托管” 之间的平衡点。它可以完全自托管，这意味着你会话管理的生死大权掌握在自己手中，不依赖任何第三方服务。同时，它保持了开源项目的可扩展性 —— 代码质量高、框架集成良好，团队可以根据自身需求进行定制。Val Town 选择 Better Auth 的核心原因正是 “不再依赖第三方保持在线状态来管理会话”。需要承认的是，Better Auth 也有供应商风险 —— 它主要由一家公司维护，但这种风险相较于将核心会话管理委托给第三方服务来说是可控的。
迁移策略与可操作参数
基于 Val Town 的实践经验，如果你正在考虑或正在进行认证供应商的迁移，以下参数和阈值可以作为参考。
在双写过渡阶段，建议将过渡期设置为至少两周。Val Town 采取的策略是在这两周内让每个认证端点同时接受旧供应商和新供应商的 cookie，新登录自动发放新供应商的 session，已登录用户的旧 session 自然过期后自动切换。这种方式虽然需要编写额外的兼容层代码，但能够实现平滑迁移，避免集中式迁移带来的服务中断风险。
在速率限制配置方面，如果你选择继续使用 Clerk，对于社交属性较强的应用，需要提前评估用户信息 API 的调用量。Val Town 遇到的 5 次 / 秒的限制对于中等规模的社交应用来说是远远不够的。建议在上线前进行压力测试，评估你的主要功能路径（如动态加载、评论系统、用户搜索）所需的用户信息 API 调用频率，并与 Clerk 的限流策略进行匹配。
在会话刷新频率上，Cookie-based 会话的刷新间隔需要权衡安全性与可用性。较短的刷新间隔意味着更快的会话失效能力（ security-wise 这是优点），但也意味着更频繁地依赖第三方服务。Val Town 的经验表明，当第三方服务不可用时，频繁的会话刷新会成为可用性的致命弱点。建议将刷新间隔设置在 15 到 30 分钟之间，并在客户端实现优雅降级逻辑 —— 当刷新失败时，在一定时间内继续使用现有 session，而不是立即失败。
在供应商选择评估时，应该重点考察以下维度：是否支持自托管或完全控制 session 数据、是否提供完善的 users 表概念供业务数据关联、API 速率限制是否满足业务峰值需求、是否具备开源核心以确保可审计性和可定制性、还有管理后台是否支持业务所需的操作。Better Auth 在这几个维度上相对均衡，而 Clerk 在 “完全托管” 的便利性与 “社交应用适配” 之间存在明显短板。
总结
认证方案的选择没有放之四海而皆准的答案。Clerk 是一个优秀的产品，对于正确的使用场景 —— 简单的、非社交的、主要面向前端的应用 —— 它提供了出色的开发体验。Supabase Auth 与 Supabase 生态紧密集成，适合已经深度使用 Supabase 的项目。Better Auth 则为那些需要在供应商风险和开发效率之间找到平衡的团队提供了一个务实的选择。
Val Town 三年三次切换认证供应商的经历教会我们：技术决策必须与业务需求相匹配。再流行的产品、再成功的公司，如果与你的架构假设不符，最终都会成为负担。在选择认证供应商时，不仅要考虑入门的便利性，更要思考它在你的特定场景下可能遇到的瓶颈 —— 这些瓶颈往往不会在 demo 阶段暴露，而是在生产环境的真实负载下才显现出来。
资料来源：Val Town 官方博客《From Supabase to Clerk to Better Auth》（blog.val.town/better-auth）