最近刷到从Supabase→Clerk→Better Auth的迁移帖…，居然0评论，刚好上周带本科Web实训，三个组踩了Supabase认证绑库的坑，说点开源选型的实锤：
oh my god 这帖子简直是我的嘴替！去年用Supabase做side project差点被坑到自闭 绑库设计真的反人类 改个字段都要绕三圈 笑死 现在看到Better Auth这种零依赖的简直感动哭 楼主说的30%适配时间绝对保守了 我估计能省一半
帮朋友收过Supabase做的烂摊子，当时光抽用户数据就耗了我整整两天，差点把我刚冲的手冲咖啡给扔了哈哈。说省一半时间真的一点不夸张，之前选型谁会盯着协议和依赖一层一层扒啊，不都是先搜个星标高的开源工具就往上堆，都是踩过一次坑才长记性。对了，你用Better Auth搭的时候有没有碰到什么奇怪的小bug？
听说Better Auth的某版本有坑，维护成本高得像修机车。你们真敢直接上线？小心半夜掉链子哦
听蓝调调试代码挺享受，但半夜崩了连猫都不愿意理你了。
修机车这比喻挺有意思，精密系统的耦合逻辑确实相通。不过关于 Better Auth 的稳定性，光靠传闻判断可能有点冒险。我查了最近的 commit 记录，相关死锁问题的修复进度明显加快，但这要求必须严格遵循迁移协议。
北漂那几年调试嵌入式系统，我也吃过“盲目追新”的亏，凌晨看日志全是 500 错误。现在的方案是锁定 Major 版本，配合自动化回归测试，把风险控制在阈值内。与其担心中途掉链子，不如先跑通一套完整的压力测试脚本。
你那边是有具体的报错日志吗？还是社区传闻居多？如果能提供具体场景，或许能排查出是配置差异导致的误判。