后端是独立开发者的最大成本

一个想法从雏形到能用，卡住大多数人的不是前端，而是后端：数据库怎么建、登录怎么做、文件往哪存、接口怎么写、部署怎么搞。每一样单独看都不难，加起来就是几周的工作量，而你的想法可能一周后就变了。

Supabase 把这些打包成一件事。它本质是一个托管的 Postgres 数据库，外加认证、存储、实时订阅和函数能力，并且自动生成可直接调用的接口。

第一步：创建项目与获取密钥

注册后新建项目，等待初始化完成（约一到两分钟）。之后在设置里能看到两个关键值：

  • Project URL：项目地址
  • anon key：匿名公钥，可安全放在前端
  • service_role key：服务端密钥，拥有绕过权限的完全访问权

第三条是安全红线：service_role key 绝不能出现在前端代码、移动端包体或公开仓库里。一旦泄露，你所有的权限控制形同虚设。

把它们放进环境变量，不要硬编码在源码中。

第二步：设计数据表

在表编辑器里建表，也可以直接写 SQL。建议用 SQL，便于版本管理和团队共享。

建表要点：

  1. 每张表都要有主键，推荐用 UUID 并设置默认值
  2. 加上 created_at 字段，默认值为当前时间戳
  3. 需要关联用户的表，加上 user_id 字段并外键关联到认证用户表
  4. 枚举类字段优先用单独的状态表或检查约束，别用裸字符串

第三点是后续权限控制的基础。没有 user_id，你就没法实现这是我的数据这种最基本的隔离。

create table notes (
id uuid primary key default gen_random_uuid(),
user_id uuid references auth.users not null,
title text not null,
content text,
created_at timestamptz default now()
);

第三步：配置行级安全策略（最重要的一步）

这是 Supabase 安全模型的核心，也是最容易被忽略的一步。

行级安全（RLS）开启后，默认拒绝所有访问——没写策略就是谁都查不到。很多人建完表发现前端查不出数据，就是因为开了 RLS 却没配策略。

正确做法：

  1. 建表后立即开启 RLS，永远不要让它裸奔
  2. 为每类操作分别写策略：查询、插入、更新、删除
  3. 策略里用 auth.uid() 匹配 user_id，确保用户只能访问自己的数据

示例策略，允许用户查看自己的笔记：

create policy 用户只能查看自己的笔记
on notes for select
using (auth.uid() = user_id);

插入策略要写成 with check，确保用户不能以他人身份插入：

create policy 用户只能创建自己的笔记
on notes for insert
with check (auth.uid() = user_id);

漏掉第二条是很常见的安全漏洞——用户能读到自己的，但能往别人的账户里写数据。

第四步：接入前端认证

安装客户端库：

npm install @supabase/supabase-js

初始化客户端，传入项目地址和匿名密钥。之后认证流程基本是现成的：

  • 邮箱注册：调用注册接口，用户会收到确认邮件
  • 邮箱登录：调用登录接口，成功后客户端自动保存会话
  • 第三方登录：在后台配置好 OAuth 应用，前端一行调用即可跳转
  • 会话监听：注册状态变化回调，用于更新界面登录态

开发阶段可以关闭邮箱确认以加快调试，但上线前必须打开，否则任何人都能用别人的邮箱注册。

第五步：增删改查

客户端提供了链式调用接口，不需要写后端代码：

  • 查询：选择表和字段，可加过滤、排序、分页
  • 插入：传入对象，可要求返回插入后的完整记录
  • 更新：必须带过滤条件，忘了加条件会更新整张表
  • 删除：同样必须带条件

更新和删除忘记加过滤条件是高频事故。建议养成习惯：写更新语句时先写过滤条件，再写要改的字段。

第六步：文件存储

创建存储桶，设置公开或私有。私有桶配合策略控制访问，公开桶适合放静态资源。

上传路径设计建议包含用户 ID，例如 user_id/filename，这样配合存储策略能实现文件级别的隔离。

注意限制上传文件类型和大小，否则存储成本会失控。后台可以设置单桶的大小上限和允许的 MIME 类型。

第七步：实时订阅

需要数据变化时自动推送给前端（例如聊天、协作、实时看板）时，开启实时功能。

配置步骤：在后台为表启用实时复制，前端订阅对应频道并监听插入、更新、删除事件。

注意：实时功能同样受 RLS 策略约束，用户只会收到自己有权看到的数据变更。这一点设计得很合理，但也意味着策略写错时实时会静默不工作。

常见问题与误区

  • 问：前端查不到数据？九成是 RLS 开启了但没配策略，或策略条件写错。检查时可以先临时关掉 RLS 验证数据本身是否存在。
  • 误区：只在前端做权限判断。前端判断只是体验优化，真正的安全必须在数据库层面用 RLS 保证。
  • 问：密钥泄露了怎么办？立即在后台轮换密钥，检查是否有异常数据访问，并排查泄露途径（常见是提交到了公开仓库）。
  • 误区：免费额度能一直用。免费项目一段时间无访问会被暂停，正式产品要规划付费方案。
  • 问：复杂业务逻辑放哪？可以用数据库函数或边缘函数实现，但要注意边缘函数的冷启动时间和运行时限制。
  • 误区：完全不需要后端。涉及支付、第三方密钥调用、复杂计算时，仍需要一个受控的服务端。Supabase 解决的是常规数据操作，不是全部后端需求。

效率数据与实测结论

以一个包含用户注册登录、笔记增删改查、图片上传的小应用为例：传统方式自建后端约需 3 到 5 天（含部署、鉴权、文件存储方案选型）；使用 Supabase 约 4 小时可跑通全流程，其中近一半时间花在理解 RLS 策略上。

时间节省是巨大的，但请把省下的时间里的一部分用于认真设计权限策略。这套方案最大的风险不是功能不够，而是配置疏忽导致的数据泄露——而这个代价，远高于多花的两天开发时间。