BaaS 与实时数据层（Supabase/Firebase/Appwrite）

• Postgres 与 RLS 行级权限
• Auth、Realtime、Storage、Edge Functions
• Supabase JS 客户端

Supabase 是开源 BaaS，基于 Postgres 提供完整后端能力：数据库（Postgres + RLS 行级权限）、Auth（认证）、Realtime（实时订阅）、Storage（对象存储）、Edge Functions（边缘函数，Deno）。Supabase JS 是客户端 SDK，提供认证、数据库查询、实时订阅与存储操作。工程价值在于：全部后端能力开箱即用，前端用 JS SDK 直接安全地访问数据库（配合 RLS），实现认证、实时与存储的一体化，适合快速构建全栈应用且数据可控。

Supabase 的价值是"Postgres 全栈 + RLS 安全 + 前端 SDK"。RLS 让前端可直接查库，是它的核心优势。

• RLS 策略的编写
• auth.uid() 的绕过
• 权限漏洞模式

RLS（Row Level Security）策略在 Postgres 中定义哪些行可被哪些用户访问，用 CREATE POLICY 编写，配合 auth.uid() 判断当前用户。常见漏洞：一、auth.uid() 绕过——若策略未正确使用 auth.uid() 或使用 auth.role() = 'anon' 等宽松条件，未认证用户可能访问数据；二、策略表达式注入——若策略拼接用户输入或包含不安全表达式，可能被绕过；三、security definer 函数风险——若用 security definer 提升权限执行，可能绕过 RLS 暴露数据。工程上需用最严格策略、测试所有角色路径、避免 privilege 提升函数泄漏数据。

RLS 安全的核心是"按用户精确授权 + 测试绕过路径"。漏洞往往源于宽松策略、表达式与权限提升函数。

• Firestore 实时监听
• 离线缓存
• 客户端订阅与一致性

Firestore 支持实时查询（onSnapshot），客户端订阅数据变化并自动更新，无需轮询；Offline Persistence 让数据在离线时缓存到本地，恢复在线后自动同步。工程价值在于：实时协作与即时更新、离线可用性、减少网络请求。工程上需处理快照的取消订阅、离线冲突与数据一致性、以及缓存大小与配额。取舍是实时性与一致性、成本与复杂度。

Firestore 实时 + 离线让"订阅式数据"体验好。工程价值是实时与离线，但需管理与一致性。

• Email 密码认证
• OAuth（Google/Apple 等）
• Anonymous 匿名认证

Firebase Auth 支持多种认证：Email/密码、OAuth（Google、Apple、GitHub 等）、匿名认证（Anonymous）等。匿名认证让用户无需注册即可使用应用，之后可升级为正式账号。工程价值在于：快速接入多种登录方式、统一认证状态、匿名到实名升级路径、简化 auth 用户管理。工程上需处理多 provider 的账户合并、Token 刷新、安全规则与用户状态管理。

Firebase Auth 的价值是"多方式认证 + 快速接入"。匿名升级与多 provider 合并是常见工程点。

• Cloud Functions 的服务端逻辑
• App Check 的设备验证
• 生产安全

Firebase Cloud Functions 用于在服务端执行业务逻辑（可信环境、密钥、复杂操作），App Check 用于验证请求来自可信的应用实例（防滥用、防 bot、防未授权调用后端）。生产环境工程价值：Cloud Functions 提供不受客户端绕过影响的服务端逻辑，App Check 保护后端与资源不被滥用。二者结合可提升生产安全与稳定性。工程上需合理划分客户端直接访问与 Cloud Functions 访问，启用 App Check 保护。

Cloud Functions 提供可信逻辑，App Check 防滥用。工程上组合使用提升生产安全。

• Firestore 查询限制
• Security Rules 的权限
• 规则设计

Firestore 查询有索引限制（复合查询需建索引）、单查询限制（范围过滤等）与数据结构约束。Security Rules 类似于 RLS，定义谁能读写哪些文档，用规则语言（request.auth、resource.data）控制。设计上需：用规则限制集合与文档的访问、按 auth 与字段校验、避免客户端绕过只读安全规则。工程上需理解查询限制（索引、单查询约束）与规则的匹配，保证查询与规则一致，防止数据泄漏。

Firestore 的价值是"查询 + 规则"。设计关键是规则匹配查询、索引管理与权限最小化。

• 各服务的能力
• 组合使用
• 前端工程价值

Firebase 生态系统包括：Firestore（NoSQL 文档数据库，实时）、Realtime Database（实时 JSON 数据库）、Auth（认证）、Storage（文件存储）、Cloud Functions（服务端函数）、App Check（应用验证）等。前端可组合使用：Auth 认证、Firestore 数据、Storage 文件、Cloud Functions 服务端逻辑、App Check 安全。工程价值在于：完整后端能力开箱即用、实时同步、跨平台，快速构建全栈应用。取舍上需注意厂商锁定、查询限制与成本。

Firebase 的价值是"完整 BaaS + 实时 + 跨平台"。工程上用其组合服务快速构建，但需评估锁定与限制。

• 各 BaaS 的定位
• 自托管 vs 托管
• 数据模型与实时

Appwrite、Pocketbase、Convex 都是 Firebase 替代方案：Appwrite 是自托管开源 BaaS（Auth、DB、Storage、Functions），可自托管控制数据；Pocketbase 是单二进制 Go 后端（SQLite + Auth + Realtime），轻量易部署；Convex 是托管型反应式数据库 + 后端函数，实时类型安全。取舍上：要自托管与完整功能选 Appwrite；要轻量单文件选 Pocketbase；要托管实时类型安全选 Convex。按数据规模、自托管需求、实时性与团队偏好选型。

替代方案在"自托管 vs 托管、轻量 vs 丰富、实时类型"上取舍。按项目需求选型。

• FCM 的 Web Push
• Service Worker 与通知
• 浏览器支持

FCM 提供 Web Push 能力，通过 Service Worker 接收推送消息并显示通知，即使页面未打开也能收到。工程价值在于：实现实时通知、营销与提醒，简化推送服务端配置。现代浏览器支持上，Web Push 主流浏览器（Chrome、Firefox、Edge）支持，iOS Safari 对 Web Push 支持有限（需 PWA 且特定条件）。工程上需处理权限请求、Service Worker 注册、通知点击与订阅管理，并注意浏览器差异。

FCM 的价值是"Web Push 实时通知"。工程上要处理 Service Worker 与权限，注意浏览器支持差异。

• 单二进制部署
• SQLite + Auth + Realtime
• 轻量 BaaS

Pocketbase 是单二进制 Go 后端，内置 SQLite 数据库、Auth（认证）、Realtime（实时订阅）与文件存储，部署简单（一个可执行文件）。工程价值在于：轻量、零外部依赖、易自托管、适合中小项目与内部工具，提供 Auth 与 Realtime 能力。边界是：SQLite 的并发与扩展性、功能深度、以及生态相对 Firebase/Appwrite 小。工程上适合中小规模与快速原型。

Pocketbase 的价值是"单文件轻量 BaaS + Auth/Realtime"。边界在 SQLite 扩展性与功能深度。

• 自托管能力
• 功能与数据控制
• 运维成本

Appwrite 是自托管开源 BaaS，提供 Auth、数据库、Storage、Functions 等，可部署在自己的服务器/容器，控制数据与基础设施。取舍上：自托管带来数据控制与隐私、无厂商锁定、可定制，但需承担运维成本、扩展性与稳定性责任；相比托管 BaaS，初期部署与维护复杂。工程上适合对数据安全、自托管有要求且具备运维能力的团队，否则考虑托管方案。

Appwrite 的取舍是"自托管控制 vs 运维成本"。工程上按数据安全与运维能力权衡。

• RLS 策略
• 前端直接查库
• 安全边界

Supabase RLS 在前端落地：前端用 Supabase JS 直接查询数据库，RLS 策略根据 auth.uid() 在服务端过滤行，保证用户只能访问自己的数据。落地要点：为每个表启用 RLS 并编写策略、前端通过认证后的 access token 携带用户身份、把敏感逻辑放在 RLS 或 Edge Functions 中、避免把不该前端执行的逻辑放客户端。边界是：RLS 保护数据访问，但业务校验（如金额、状态）仍需服务端（Edge Functions）保证。

RLS 落地让前端"安全直查数据库"。工程上关键是把授权与业务校验分离，RLS 管授权。

• RLS 的定义
• 策略与权限
• 前端安全

Supabase 的 Row Level Security（RLS）是 Postgres 的行级安全机制，通过策略控制哪些行可被哪些用户查询/插入/更新/删除。策略用 auth.uid() 等判断当前用户，实现"用户只能访问自己的数据"。工程价值在于：让前端可以直接安全地查询数据库，无需中间层为每个请求过滤，是 Supabase 前端直连的安全基石。部署时需为所有涉及的表启用 RLS 并编写最小化策略。

RLS 是 Postgres 行级授权，是 Supabase 前端直连的安全核心。工程上必须启用并写策略。

• Realtime 的订阅
• 事件监听（insert/update/delete）
• WebSocket

Supabase Realtime 基于 WebSocket 提供实时订阅，客户端可订阅表的变更（postgres_changes 的 insert/update/delete）、broadcast（广播）与 presence（在线状态）。前端用 supabase.channel() 创建频道并 .on('postgres_changes', ...) 监听事件，收到变更后更新 UI。工程价值在于：实时协作、即时更新、无需轮询。工程上需管理频道订阅与取消、处理连接状态与重连、以及事件频率与性能。

Realtime 的价值是"WebSocket 实时订阅 + 事件监听"。工程上要管理订阅生命周期与重连。

• RLS 的服务端强制执行
• 前端只是展示层
• 白盒测试

RLS 在 Postgres 服务端强制执行，前端无论怎么修改代码都无法绕过服务端的 RLS 策略，因此"前端绕过 RLS"通常指白盒测试（有权限的直接用 SQL/API 测试策略是否正确），而非真正攻破。安全边界是：RLS 保证数据访问授权，但如果策略本身写错（宽松、未用 auth.uid()），合法 API 也会返回不该返回的数据。工程上应把安全核心放在服务端 RLS 策略，前端只负责展示与正确调用，并通过白盒测试验证策略。

RLS 是服务端强制，前端无法绕过真实策略。安全边界在策略正确性，前端绕过只是白盒验证。

• Realtime 的实时同步
• CRDT 与 Yjs
• 协同编辑架构

Supabase Realtime 可用于协同编辑的数据同步：通过广播（broadcast）或 presence 传递变更，或把文档状态存到数据库。CRDT（如 Yjs）是无冲突的协同数据结构，用于解决多方并发编辑的冲突合并。工程上常把 Yjs 文档与 Realtime 结合：用 Realtime 的 broadcast 在客户端间同步 Yjs 更新，或把 Yjs 状态持久化到数据库。价值在于：实时协同、冲突解决、多人编辑。工程上需处理更新频率、背压与状态持久化。

Realtime + Yjs 让"协同编辑"实现。Realtime 传输、Yjs 解决冲突，工程上需处理同步与持久化。

• Realtime 吞吐限制
• 背压处理
• 消息合并与节流

Realtime 有吞吐上限（每 channel 消息速率、连接数等），高频更新可能触发限流或丢消息。背压处理：当客户端消费速度跟不上时，需降频或合并消息。工程上高频更新场景采用：消息合并（把短时间内的多个变更合并为一次 UI 更新）、客户端节流（限流订阅事件或批量更新）、以及降级（关闭某些实时订阅或抽样）。价值在于避免 UI 卡顿与连接受限。工程上需衡量实时性与性能，用合并与节流策略平衡。

高频更新需"合并 + 节流"应对背压。工程上要控制订阅频率与 UI 更新，平衡实时性与性能。

• 冷启动优化
• 区域部署与就近路由
• 延迟优化

Supabase Edge Functions 基于 Deno，冷启动影响延迟。优化手段：减小 bundle 体积、减少依赖、延迟初始化、用 Web 标准 API、避免重初始化。区域部署与就近路由：把函数部署到离用户近的区域，或借助路由（如 Cloudflare/Custom domain）就近执行，减少网络延迟。工程实践上应结合函数所在区域与用户分布，选择合适区域部署，并优化冷启动以降低首次请求延迟。

延迟优化靠"精简函数 + 就近部署"。工程上要权衡冷启动与区域一致性。

• Edge Functions 的服务端逻辑
• SSR/BFF 协同
• 安全与密钥

Supabase Edge Functions（Deno）可作为 BFF（Backend for Frontend）或 SSR 的服务端层，执行需要密钥、复杂校验或服务端逻辑的操作，避免把密钥暴露给前端。协同 SSR/BFF 时，Edge Functions 处理 Auth、数据聚合、权限校验，再把结果给 SSR 渲染或前端调用。工程价值在于：密钥与服务端逻辑安全、减少前端暴露、提供可控的服务端能力。工程上需管理 Edge Functions 的部署、权限与调用。

Edge Functions 作为 BFF 的价值是"服务端逻辑 + 密钥安全"。工程上用来承载 SSR 所需后端逻辑。

• Storage 的 RLS
• S3 兼容
• 文件上传安全

Supabase Storage 提供对象存储，支持 RLS 策略控制文件访问，并兼容 S3 API。工程价值在于：文件上传/下载可结合 RLS 做权限控制（用户只能访问自己的文件）、兼容 S3 便于迁移与工具集成、支持上传签名与 CDN。上传实践上，前端用 SDK 上传，服务端/Rls 控制访问，可配置 MIME 与大小限制。取舍上 S3 兼容性带来便利，但需注意与 S3 生态的差异。

Storage 的价值是"RLS 文件权限 + S3 兼容"。工程上用于安全文件上传与访问控制。

• 多 Provider 支持
• 账户合并
• 认证流程

Firebase Authentication 支持 Email、Google、Apple、GitHub 等多个 Provider，前端可提供多种登录方式。工程上需处理：多 Provider 的登录流程、账户关联与合并（同一用户用不同方式登录时合并账户）、Token 刷新与用户状态管理、以及安全规则依据。工程价值在于：多端多方式登录、统一身份、简化认证。取舍是多 Provider 带来账户合并复杂度。

多 Provider 的价值是"多登录方式 + 统一身份"。工程上需处理账户合并与状态管理。

• Security Rules 的语法
• 权限控制
• 规则设计

Cloud Firestore 的 Security Rules 用规则语言定义集合/文档的读写权限，基于 request.auth、request.resource、resource.data 等判断。设计上：为每个集合定义读写规则、用 auth 限制用户访问、校验字段与数据、用 role 区分读写、避免宽松 allow read: if true。工程价值在于：让客户端在安全规则下直接访问数据库，无需中间层。工程上需测试规则、保证查询与规则一致，防止数据泄漏。

Security Rules 是 Firestore 的访问控制。设计关键是按用户授权、字段校验与规则测试。

• Realtime DB 的 JSON 树
• Firestore 的文档模型
• 查询与实时

Firebase Realtime Database 用 JSON 树结构，实时同步、简单低延迟，但查询能力弱、数据嵌套需谨慎；Firestore 是文档型 NoSQL，支持复杂查询、索引、事务与安全规则，结构更清晰。取舍上：Realtime DB 适合简单实时数据、低延迟、小规模；Firestore 适合结构化数据、复杂查询、可扩展应用。工程上应按数据模型、查询需求与实时性选型，Firestore 通常更通用。

取舍是"简单实时树 vs 文档查询"。Firestore 查询强、Realtime DB 简单实时，按需求选型。

• 静态站点部署
• CDN 缓存
• 边界与重写

Firebase Hosting 提供静态站点托管与 CDN，支持一键部署、缓存控制、重写与函数集成。工程价值在于：快速部署静态站点/PWA、CDN 加速、可配置重写与 headers。现代边界是：它主要面向静态与轻量动态（通过 Cloud Functions/重写），复杂 SSR 与动态渲染需结合其他方案；缓存策略需配置合理。工程上适合静态站与前端资源，动态能力需配合 Functions。

Firebase Hosting 的价值是"静态托管 + CDN + 重写"。边界在动态/SSR 能力，需结合 Functions。

• 数据建模与契约
• 迁移与版本
• 密钥与可观测性

使用 BaaS 不意味着可省略后端基础工程：数据建模（表结构、索引、关系）决定性能与正确性；接口契约（规则、权限、协议）保证前后端一致；迁移管理（schema 变更、版本）保证演进可控；密钥管理（服务端密钥、环境变量）保证安全；可观测性（日志、监控、错误）保证可排障。这些基础概念对 BaaS 应用同样关键，省略会导致数据混乱、安全风险与运维困难。工程上应像对待自有后端一样对待 BaaS。

BaaS 只是"托管后端"，基础工程不可省。数据建模、契约、迁移、密钥、可观测性决定生产质量。

• broadcast 广播
• presence 在线状态
• db changes 数据库变更

Supabase Realtime 基于 WebSocket 提供三种机制：broadcast（向频道用户广播消息，无需写库）、presence（在线状态与用户列表）、db changes（订阅数据库表变更，insert/update/delete）。工程价值在于：broadcast 用于实时消息/协作、presence 用于在线状态、db changes 用于数据驱动的实时更新。工程上按需选择机制，管理订阅与频道权限。

三种机制覆盖"消息、状态、数据变更"的实时需求。工程上按场景选用并管理权限。

• JWT 认证
• RLS 联动
• 前端安全

Supabase Auth 签发 JWT，携带用户身份（uid、role），前端把 JWT 传给数据库操作，Postgres 的 RLS 用 auth.uid() 从 JWT 解析用户并过滤行。这一"JWT + RLS"联动让前端能安全直连数据库：认证由 Auth 完成、授权由 RLS 完成，前端无需后端中间层。工程价值在于：安全、简化、实时。工程上需正确配置 RLS 策略与 JWT 校验，避免越权。

JWT + RLS 联动是"认证 + 授权"的闭环。前端直连安全的基础，工程上需严格写策略。

• pg_cron 定时任务
• Edge Functions 边缘计算
• 应用场景

Supabase 的 pg_cron 在数据库中执行定时任务（定期清理、聚合、触发），Edge Functions 在边缘执行服务端逻辑（API、webhook、AI 调用）。工程应用上：pg_cron 用于数据库内的定时作业（如清理、报表），Edge Functions 用于事件驱动与边缘计算（如处理回调、定时触发外部服务）。工程价值在于：定时任务与边缘逻辑无需自建服务，集成在 Supabase。工程上需管理调度与权限。

pg_cron 管数据库定时任务，Edge Functions 管边缘逻辑。工程上结合使用减少自建服务。

• OAuth 外部登录
• JWT 集成
• 第三方认证

Supabase Auth 支持 OAuth（Google、GitHub 等）登录，签发 JWT 给前端，前端携带 JWT 访问数据库与 RLS。集成上，可配置 OAuth Provider、获取第三方 Token、处理回调与刷新。工程价值在于：让用户用第三方账号登录、简化注册、统一 JWT 身份。工程上需配置 Provider 回调、环境变量、Token 管理，并与 RLS 联动。

OAuth + JWT 集成让"第三方登录 + 统一身份"。工程上配置 Provider 与 JWT 联动 RLS。

• 多端 SDK
• 跨平台能力
• 统一后端

AppWrite 是开源 BaaS，提供 Web、App（Flutter、React Native 等）的多端 SDK，统一提供 Auth、数据库、Storage、Functions。工程价值在于：一套后端服务多端复用，降低后端成本；自托管可控数据。多端应用时，各端用对应 SDK 访问同一后端，共享认证与数据。工程上需管理多端权限、SDK 版本与数据一致性。

AppWrite 的价值是"多端统一后端 + 自托管"。工程上让 Web/App 共享后端能力。

• 单二进制部署
• 中小项目
• 快速上线

PocketBase 是 Go 单二进制 BaaS，内置 SQLite、Auth、Realtime、文件存储。中小项目应用价值：部署简单（一个可执行文件）、零外部依赖、快速上线、易自托管，提供认证与实时能力。工程应用上适合中小项目、内部工具、快速原型与个人项目。边界是 SQLite 扩展性与功能深度，复杂需求需迁移或补充。工程上按项目规模选型。

PocketBase 的价值是"单文件 + 轻量 + 快速"。适合中小项目，边界在扩展性。

• auth.uid() 的用途
• RLS 策略编写
• 安全实践

auth.uid() 在 Supabase RLS 中返回当前认证用户的 ID，用于策略判断。工程实践：在策略中用 auth.uid() = id 限制用户只能访问自己的数据、用 auth.role() 判断角色、避免把 auth.uid() 用于不可信场景。要点：为所有表启用 RLS、写最小化策略、测试 unauthenticated 与 authenticated 路径、避免将 auth.uid() 与 user_id 不匹配导致数据泄漏。工程上配合授权与业务校验。

auth.uid() 是 RLS 的用户身份来源。实践关键是正确引用、最小化授权与测试绕过。

• postgres_changes 订阅
• 协作功能
• 实时更新

Supabase 的 postgres_changes 实时事件可订阅数据库表的 insert/update/delete，用于协作功能：多用户同时编辑文档、即时评论、任务状态同步、实时数据看板。前端订阅频道并对变更事件更新 UI，实现多人实时协作。工程应用上需选择合适的表与事件、管理订阅权限、处理高频更新与冲突。价值在于：基于数据库变更的实时协作，简化实现。

postgres_changes 让"数据库变更"驱动实时协作。工程上用于协作与实时更新，需管理订阅。

• Crashlytics 的崩溃监控
• 错误上报
• 前端稳定性

Firebase Crashlytics 提供崩溃与错误监控，Web 端可上报 JavaScript 错误、未捕获异常与自定义错误，帮助定位前端稳定性问题。工程价值在于：实时掌握崩溃率、错误堆栈、用户影响，支持版本与发布跟踪，提升稳定性。工程上需在应用初始化 Crashlytics、捕获未处理的错误、上报上下文，并设置非致命错误与崩溃分级。取舍上它与 Firebase 生态绑定。

Crashlytics 的价值是"前端崩溃监控 + 错误定位"。工程上用于稳定性治理与错误上报。

• Functions 的触发
• 事件驱动
• 服务端逻辑

AppWrite Functions 支持事件触发（如数据库变更、文件创建、定时任务）与 HTTP 触发，用于事件驱动的服务端逻辑。工程价值在于：把数据库/存储事件作为触发源，自动执行后续逻辑（如通知、处理、聚合），无需自建事件系统。事件渲染上，Functions 提供无服务器的执行环境，按需触发。取舍上，需管理超时、冷启动与权限。

AppWrite Functions 的价值是"事件驱动 + 无服务器"。工程上用触发器执行后续逻辑。

• Admin UI 的管理
• 内部工具
• 数据管理

PocketBase 内置 Admin UI，用于管理集合（表）、数据、用户、规则与文件，无需自建管理界面。工程应用上，内部工具与团队可借助 Admin UI 直接查看/编辑数据、管理 Auth 用户与权限、配置集合规则，快速维护数据。工程价值在于：省去搭建管理后台的成本，适合中小项目与内部工具。边界是 Admin UI 是通用管理，复杂业务操作仍需自定义。

Admin UI 的价值是"开箱即用的数据管理"。工程上用于内部工具的数据维护，减少后台开发。

• Extensions 的扩展
• 第三方集成
• 快速接入

Firebase Extensions 是可复用的功能扩展，提供预构建的第三方集成（如 Stripe、支付、邮件、图像处理等），可通过配置快速接入。工程价值在于：减少自研集成成本、快速添加功能、可维护。工程上按需安装扩展、配置触发与参数、关注扩展的版本与维护。取舍上，扩展灵活但受限于其能力与抽象，复杂集成仍需自定义。

Firebase Extensions 的价值是"预构建第三方集成 + 快速接入"。工程上用于加速功能落地。

• Realtime 的 WebSocket
• 实时订阅
• 实时更新

AppWrite 的 Realtime 基于 WebSocket，提供实时订阅（数据库集合、文档、文件、用户等变化），前端订阅后自动接收更新。工程应用上用于实时协作、通知、数据看板与状态同步。价值在于：无需轮询即可实时更新，提升体验。工程上需管理订阅、权限与连接，控制事件频率。

AppWrite Realtime 的价值是"WebSocket 实时订阅"。工程上用于实时更新与协作。

• Remote Config 的参数
• 功能开关
• 动态配置

Firebase Remote Config 提供云端参数配置，前端可动态获取参数（如功能开关、文案、阈值），无需发版即可控制功能。工程应用上：功能开关（feature flag）、A/B 测试、灰度发布、动态配置。价值在于：快速调整功能、降低发布风险、按用户/条件分发。工程上需管理参数默认值、缓存与刷新策略、以及参数与用户分组的绑定。

Remote Config 的价值是"云端动态配置 + 功能开关"。工程上用于灰度与动态调整。

• CLI 的本地开发
• 本地 Postgres 与迁移
• 与生产同步

Supabase CLI 提供本地开发环境：本地启动 Supabase（Postgres、Auth、Realtime）、管理迁移、生成类型、部署 Edge Functions。工程实践：用 CLI 本地启动、用 migration 管理 schema 变更、supabase gen types 生成类型、supabase link 关联生产并部署。价值在于：本地与生产一致、schema 可版本化、类型安全。工程上应把 schema 迁移纳入版本控制，规范化本地开发流程。

Supabase CLI 的价值是"本地开发 + 迁移 + 类型生成"。工程上让本地与生产一致、schema 可管理。

• 厂商锁定的程度
• 开源 vs 托管
• 迁移成本

Firebase 是闭源托管服务，厂商锁定较强（专有 API、数据库、规则），迁移成本高；Supabase 基于开源 Postgres 与标准化 API，可自托管、数据可迁移，锁定相对较低。取舍上：Firebase 体验与生态成熟但锁定强；Supabase 开源、DB 用 Postgres 可迁移、可自托管，锁定低。工程上需评估锁定风险、迁移成本与数据控制需求，选择符合长期策略的平台。

锁定差异源于"闭源托管 vs 开源可自托管"。Supabase 用 Postgres 降低锁定，工程上按数据控制需求权衡。

• 三者的数据模型
• 实时与类型
• 取舍

Convex、Supabase、Firebase 都是全栈 BaaS + Serverless DB：Convex 是托管反应式数据库 + 后端函数，类型安全、实时、事务，但锁定；Supabase 基于 Postgres 开源、RLS、可自托管，SQL 能力与生态；Firebase 闭源托管、Firestore 文档、生态成熟、查询与规则。取舍上：要类型安全与反应式选 Convex；要开源/SQL/可自托管选 Supabase；要生态成熟与多端选 Firebase。按实时性、数据模型、自托管与锁定需求选型。

三者差异在"数据模型 + 实时 + 开源/锁定"。工程上按项目需求与战略权衡。