呱呱 数据库
使用 Supabase 构建后端时：认证、数据库、实时…
在基于 Supabase 开发后端（PostgreSQL + 认证 + 实时 + 存储 + Edge Functions）时，指导写出安全、高效、可用的代码。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 38/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
使用 Supabase 构建后端时：认证特定
解决思路
- 编写正确、最新、无 bug、功能完整可运行、安全、高性能且高效的代码
- 为数据获取组件实现全面的错误处理和加载状态
- 使用 Row Level Security（RLS）策略保护数据
- 在合适场景下利用 Supabase 的实时能力
- 实现正确的 Supabase 认证流程
- 使用 RLS 策略做授权
- 正确处理认证状态变化
- 实现安全的会话管理
- 使用合适的认证提供方（email、OAuth 等）
- 设计高效的 PostgreSQL schema
- 使用合适的数据类型和约束
- 实现外键关系
- 为查询性能创建合适的索引
- 用 migrations 管理 schema 变更
- 适当使用 Supabase 实时订阅
- 为订阅实现正确的清理
- 处理连接状态和重连
- 过滤订阅以减少数据传输
- 使用 Supabase Storage 进行文件管理
- 为 bucket 实现正确的访问控制
- 处理文件上传/下载并做好错误处理
- 使用 signed URLs 实现安全访问
- 使用基于 Deno 的 Edge Functions 实现无服务器逻辑
- 为 Edge Functions 实现正确的错误处理
- 使用环境变量存放密钥
- 正确处理 CORS
- Next.js：在合适处使用 React Server Components
- Next.js：实现最小化的客户端组件
- Next.js：用正确的缓存处理数据获取
- SvelteKit：利用 SSR 特性
- SvelteKit：使用 Svelte stores 做状态管理
- 始终使用 RLS 策略
- 在服务端校验输入
- 使用 prepared statements（由 Supabase 客户端处理）
- 实现正确的错误日志记录，且不暴露敏感数据
适用边界 · 注意事项
- 项目不使用 Supabase（如自建 PostgreSQL 或其他 BaaS）时，RLS、Edge Functions、Storage 等 API 与工作流不适用
- 纯静态站点或不需要认证、数据库、实时能力的应用，引入这些模式属于过度设计
- 无法使用 Supabase 云服务或自托管实例（依赖外部服务/账号）时无法落地