Supabase：把 getUser() 换成 getClaims() 可加速应用并降低数据库负载

技术机制 vs 业务场景的对立

Supabase 这条推荐背后有两个函数的根本差异：getUser() 会向 auth.users 表发起一次数据库查询，同时验证 JWT signature 并检查用户是否存在；getClaims() 则纯解析 JWT payload，不触库。在 Supabase 的架构里，这意味着一次网络往返和一次 DB 查询 vs 纯内存操作的差距。

Supabase 的立场与历史脉络

Supabase 从一开始就走"去数据库中心"的路线：Edge Functions、Firestore-style 实时订阅、分层缓存。这次推荐是同一逻辑的自然延伸——把能不做 DB 查询的工作移到计算层完成。

但这里存在一个值得关注的利益张力：Supabase 的计费模型与数据库使用量强相关（连接数、查询量）。建议开发者"少查库"固然是工程最佳实践，同时也是降低用户账单的行为。这种双重受益让建议的权威性略打折扣。

反共识 push back

安全性派的反驳：getUser() 查库的核心价值不只是"用户存不存在"，而是能在用户被禁用、角色被修改