Supabase：圍繞 Postgres 組織全套應用服務

Postgres 是數據核心，周邊服務各有邊界

Supabase 的 README 將數據庫能力、認證、存儲、Realtime 與函數放在同一個開發平台中。Postgres 负責關系數據和 SQL，Auth 管理用戶與會话，Storage 面向文件，Realtime 用於訂閱數據庫事件，Edge Functions 负責邊緣执行。平台提供 JavaScript/TypeScript、Flutter 等官方客戶端與各服務的獨立包。

這種組合减少了應用層連接多個供應商的工作，但權限邊界仍然要分別設計。數據庫表的访問策略不能由前端界面代替，文件 bucket 的讀寫规则也不等於數據庫 RLS。README 的列表說明服務存在，並没有證明每種組合在任意规模和区域都滿足要求。

supabase 的邊界還要從輸入和輸出两端確認。輸入端記錄版本、配置、凭證來源、操作系統和依赖，輸出端記錄文件、日志、网络请求、状態變化和錯誤信息。一次通過只能證明這組条件下可運行，不能替代升級后的回归。对項目 README 没有明確說明的功能，驗收报告應保留“文檔未說明”的標記，並把實際观察與作者聲明分開。這样在后续換机器、換版本或換數據時，团队才能定位差異來自哪里。

supabase 的失败路径也應成為測試样本。故意提供无效參數、缺少依赖、過期凭證、不可访問的路径和中途退出，記錄程序是拒绝、重試、部分完成還是留下残留。若項目會触碰远程服務、Docker、模型或用戶數據，應在隔離账號與临時目錄中执行，並在結束后清除測試资源。README 描述的是項目能力邊界，具體故障恢復、權限最小化和數據清理仍需由使用方確認。

本地開發先把迁移當成主入口

README 的本地開發章節圍繞 Supabase CLI、項目目錄和數據庫迁移展開。一個可復核的流程應先初始化項目，創建迁移，啟動本地服務，再用客戶端或 SQL supabase驗證 schema。迁移文件是团队協作和環境重建的關鍵記錄，不能只在云端控制台手工改表。

測試時應從空數據庫開始执行迁移，检查表、索引、触發器和策略是否一致；再重復执行或执行回滚路径，观察 CLI 的錯誤是否清楚。若本批素材未明確某個命令的當前參數，就應以 README 與对應官方文檔為準，避免把舊版 CLI 寫法直接帶入脚本。

選擇 supabase 時還要把“能做什么”和“怎样维护”放在同一张表中。記錄首次安装需要的工具、默認路径、啟動入口、可選服務和必須锁定的版本。对配置項逐個寫明來源，不把示例值當成生產默認值。若 README 只给出了概念介绍，就回到对應官方文檔核对參數；若两處說明不一致，以實際版本的命令輸出和仓庫文件為準，並在記錄中注明差異。

supabase 的回归样例應尽量小而穩定。固定輸入后保存一次成功結果，再保存一次预期失败結果，確保升級時能發現行為改變。对於网络、模型、远程仓庫或容器服務，記錄是否访問外部资源、哪些數據會持久化、停止后怎样清理。对於纯本地流程，仍要检查日志中是否出現秘密和临時文件。這样的記錄能把項目 README 中的事實转成可重復的工程supabase判斷。

RLS 決定前端能看到什么

以 Postgres 為核心的平台通常把行級安全策略放在數據访問的中心。Supabase README 的服務定位支持使用數據庫和 Auth 組合構建應用，但具體策略仍必須按表、角色和操作逐項寫出。匿名用戶、已登錄用戶、服務角色和后台任務不應共享同一組凭證。

隔離supabase驗證可以準備两名測試用戶和一条不屬於當前用戶的記錄，分別從浏览器客戶端、服務端密钥和 SQL 管理連接發起讀取與寫入。記錄實際返回的行、錯誤碼和审計日志。服務端密钥繞過策略的风险尤其需要单獨审查，README 没有替部署方完成這項設計。

supabase 的版本記錄還應包含實際执行日期、系統版本和關鍵依赖版本。出現差異時先回看這三項，再定位配置或輸入變化。

客戶端庫與 Realtime 需要一起驗

官方 JavaScript/TypeScript 客戶端拆出 core、postgrest、auth、realtime、storage 和 functions 包，Flutter 也有对應仓庫。客戶端的便利來自統一初始化和類型化調用，但版本並非自然一致。升級時應锁定主客戶端與子包版本，检查認證刷新、文件上传和函數調用是否仍能工作。

Realtime 不應只用“能收到一条事件”supabase判斷可用性。測試應包含訂閱建立、過滤条件、网络短暂斷開、重連后的重復事件和權限變化。README 首页没有给出丢失事件的恢復語義或消息保留時間，因此需要按业務是否允许遗漏來設計补偿查询。

升級后還要重開编辑器，確認配置加载顺序和插件錯誤提示没有改變；再检查新舊快捷鍵、終端行為和語言服務器連接。

Storage、Functions 與邊緣部署

Storage 面向对象和文件，Functions 适合承载后端逻辑。部署時要明確文件權限、公開 URL、上传大小、刪除流程，以及函數如何讀取數據庫和秘密。平台把這些能力集中提供，但集中入口不會自動解決跨服務事務：文件上传成功而业務記錄失败時，應用仍需清理或重試。

在隔離項目中上传一個私有文件，使用不同身份访問籤名 URL，再触發一個只讀函數检查鉴權上下文。观察日志是否泄露 token、函數超時如何返回，以及重復触發是否產生重復副作用。README 未在摘要中承诺統一的执行時限和成本模型，正式supabase采用前需查當前文檔與計划。

選擇云端還是自托管

Supabase 的平台模式可让团队使用托管服務，也可圍繞開源組件建立自己的部署流程。云端省去部分基礎設施管理，但受地区、价格、配额和服務變更约束；自托管增加數據庫升級、備份、监控、网络和密钥轮換責任。README 的組件清单不能替代灾備演练。

上線supabase评估應明確恢復点目標、恢復時間目標、迁移审批人和數據導出方式。先在本地supabase驗證 schema 與 RLS，再用非生產數據測云端連接和限制。只有當備份恢復、權限測試和客戶端回归都可重復，才适合把平台作為主要后端。

Supabase 的驗收記錄應以迁移文件為準，而不是只記錄控制台截图。建立两個測試用戶和一組帶 owner 字段的表，寫出 select、insert、update、delete 四種 RLS 斷言，再用服務端密钥单獨supabase驗證后台路径。上传私有文件，检查未授權请求、授權请求、籤名 URL 過期和刪除后的返回。让一個 Edge Function 讀取當前會话並寫入一条审計記錄，随后測試重復調用和超時。Realtime 要覆蓋訂閱、過滤、斷网重連和补偿查询。最后從空數據庫重放迁移，在本地和目標環境比较 schema、索引、触發器與策略，避免平台服務的便利掩蓋了數據邊界。

編輯結論

适合希望以 Postgres 作為业務數據核心，同時需要認證、对象存儲、實時訂閱和函數接口的應用团队；不适合把平台組件清单當成自己的容量、合规或故障恢復證明。先用本地項目驗證迁移、RLS、客戶端请求、Realtime 訂閱和函數部署，再核对云端計划的限制與備份策略。

官方來源

1. Official documentation
2. Official README
3. Project repository
4. Release notes