6.1 快速原型开发与 MVP 构建

6.1 快速原型开发与 MVP 构建

反问一句：你有多少次因为"后端要先搭两周"把一个好点子拖黄了？Supabase 对独立开发者和小团队最大的价值，就是把后端从"项目的前提"变成"下午就能搞定的一层"。这一节我们讲怎么用最短路径做出一个能验证想法的 MVP。

先给一张清单：MVP 到底要几块

一个能验证需求的 MVP 通常只需要：认证（区分用户）、一两张业务表、RLS（数据安全）、前端调用。不用实时、不用函数、不用存储，先把核心回路跑通。下面用一段 SQL 起一个"待办 MVP"的全部后端：

-- 用户表自动来自 Auth，只需建业务表
create table public.todos (
  id bigint generated always as identity primary key,
  user_id uuid references auth.users(id) on delete cascade,
  content text not null,
  done boolean default false
);

alter table public.todos enable row level security;

create policy "自己的待办"
  on public.todos for all
  using (auth.uid() = user_id)
  with check (auth.uid() = user_id);
​

就这三段，后端完成。前端用 supabase-js 的 from('todos').select() 即可，零自建 API。

用示例库提速

基于官方 Next.js 示例库起项目，登录页、回调、会话持久化都现成：

npx create-next-app@latest todo-mvp --example with-supabase
cd todo-mvp && npm run dev
# 打开即有注册登录页，接上上面的 todos 表就能用
​

下面 SVG 画了"MVP 后端时间线"，对比传统自搭与 Supabase 的耗时差异：

展开案例：周末做出的活动报名 MVP

背景：一个线下活动主办方要在三天后开放报名，没预算没后端人力。

操作过程：

1. 用 Supabase 建 signups 表（姓名、手机号、场次），RLS 让匿名可插入、本人/管理员可读。
2. 用示例库起一个极简页面，表单直接 insert 到 signups。
3. 管理员用 Dashboard 的 Table Editor 看报名列表，无需写后台。
4. 三天后活动结束，导出 CSV（pg_dump 或 Table Editor 导出）做后续联系。

create table public.signups (
  id bigint generated always as identity primary key,
  name text not null,
  phone text not null,
  session text not null,
  created_at timestamptz default now()
);
alter table public.signups enable row level security;
create policy "匿名可报名" on public.signups for insert with check (true);
create policy "管理员读" on public.signups for select
  using (auth.jwt() ->> 'app_role' = 'admin');
​

结果：从零到可用不到一下午，活动顺利收集到 300+ 报名，主办方零后端成本。

解读：这个案例里 Supabase 的价值不是"技术多强"，而是"把后端成本压到可忽略"。活动类短期需求最怕为它养一套后端，Supabase 让它变成一次性投入。

变式：若担心匿名插入被刷，加一个轻量 Edge Function 做验证码或频率限制，再决定插不插——这时函数才值得出场，平时 MVP 阶段不必。

三句话带走本节

• MVP 只需认证 + 业务表 + RLS，不必一上来就堆实时/函数。
• 示例库把登录等脚手架现成化，省天级工作量。
• 短期活动类需求最适合 Supabase，后端成本可忽略。

提醒：MVP 阶段容易"为了快"跳过 RLS 直接公开表。即使只是验证想法，也花三分钟开 RLS——验证期的数据（手机号、邮箱）同样敏感，泄露一样要担责。

建议：我们建议 MVP 先把"核心回路"（用户+主数据+权限）跑通，实时、存储、函数等按真实需要再加。过早加组件只会拖慢验证速度。

MVP 与"真上线"之间的差距清单

MVP 能跑通想法，但要变成真能扛人的产品，有几道必须补的坎。下面把 MVP 阶段常省略、上线前必须补的项列成表，免得"验证完直接上线"踩空：

💡 关键直觉：MVP 和生产的差别不在"功能多不多"，而在"防御够不够"。MVP 省的是非核心功能，不是安全设施。前面 2.3、4.2、4.3 讲的 RLS、备份、密钥管理，本就是 MVP 阶段就该顺手做掉的低成本的"保命项"。

再展开一个案例：MVP 一周后被迫紧急加固

背景：一个活动报名 MVP（就是上节那个）火了，三天收到 300+ 报名，但主办方发现有人用脚本狂刷报名，且后台能看到所有人手机号。

操作过程：

1. 防刷：加一个轻量 Edge Function 做频率限制，再决定是否插入——MVP 阶段刻意没用函数，此时才值得出场：

// 限流函数：同 IP 1 分钟最多 5 次
const ip = req.headers.get('x-forwarded-for') ?? ''
const { data } = await admin.from('signup_logs')
  .select('id', { count: 'exact' })
  .eq('ip', ip)
  .gte('created_at', new Date(Date.now() - 60000).toISOString())
if ((data?.length ?? 0) >= 5) return new Response('太频繁', { status: 429 })
​

2. 隐私：把 signups 的读策略收紧，只有管理员（带 app_role=admin 的 JWT）能读手机号，匿名只许插入：

alter policy "管理员读" on public.signups
  using (auth.jwt() ->> 'app_role' = 'admin');
-- 匿名插入策略保持 with check(true)，但绝不开匿名读
​

3. 备份：给项目开自动备份，防误删报名数据。
4. 结果：刷单止住，手机号不再裸奔，数据有兜底。

解读：这个案例说明 MVP 不是"永远凑合"，而是"先验证、后按需加固"。验证一旦成立（有真实用户、有真实数据），该补的安全项立刻补——别等出事。Supabase 的好处是这些加固都是几行 SQL/函数，半天能补完。

⚠️ 常见坑：有人在 MVP 火了之后，为了"快"直接把后台地址发给同事看数据，且后台用的是带全部权限的账号。临时分享极易变成长期敞口。正确做法是给同事开只读、受限的 Dashboard 账号，且活动结束就收回。

下一节我们看实时协作：聊天、在线文档、看板这类"多人同屏"的产品，Supabase 怎么撑。