2.3 Supabase Dashboard：项目管理与可视化

2.3 Supabase Dashboard：项目管理与可视化

一张图先给印象：Supabase 的 Dashboard（也叫 Studio）就是你在浏览器里操作整个后端的中控台。建表、写策略、看实时日志、管用户、传文件，全在一个界面里。这一节我们不讲"点哪个按钮"，而是讲它背后的能力分区，以及它和代码/CLI 的关系——因为生产环境里你迟早要把手动操作变成可版本化的迁移脚本。

如果不这么做会怎样：可视化是把双刃剑

Studio 左侧导航大致对应我们前面讲的组件：

• Table Editor：可视建表、加列、插数据，背后生成的就是 SQL DDL。
• SQL Editor：直接跑任意 SQL，含迁移、策略、函数；能保存常用片段。
• Authentication：看用户列表、发重置密码邮件、配第三方登录提供商。
• Storage：建 bucket、传文件、看权限。
• Realtime：开/关某个表的实时监听、看频道。
• Edge Functions：看已部署函数、查日志。
• Database：连池状态、扩展开关、备份与分支。
• Logs：API、Auth、数据库、函数各类日志汇聚。

下面 SVG 把这些分区和底层组件对应起来，帮你建立"界面按钮 → 后端服务"的映射：

Dashboard 与代码的关系：别只靠点

新手最容易踩的坑：所有表结构、策略都在 Dashboard 里手动点出来，结果换个人、换环境就丢。正确姿势是：Dashboard 用来探索和验证，SQL Editor 里写好的脚本存成迁移文件，用 CLI 管理。

# 把本地在 Dashboard 里试出来的表结构，落成迁移文件
supabase migration new create_profiles

# 把本地迁移推到云端项目
supabase db push
# Applying migration 20240101000000_create_profiles.sql ... ok
​

这样一来，数据库结构是可版本化、可回滚、可评审的，而不是藏在某个人的浏览器里。

可视化里最该用好的两块

Table Editor 的 RLS 开关：每个表在编辑器里能一键 enable RLS，并可视化建策略。但可视化策略最终还是生成 SQL，复杂条件（嵌套 exists、多表关联）还是得手写。我们建议：简单策略用界面，复杂策略用 SQL Editor，然后把生成的 SQL 收进迁移。

Logs 面板：生产出问题时，这里是第一现场。API 日志能看到每条请求的响应时间和错误码；Auth 日志能看到登录失败原因；数据库日志能看到慢查询。下面是一段在 SQL Editor 里查慢查询的实操，等价于看日志但更灵活：

-- 开启 pg_stat_statements 扩展后，查最耗时的语句
select query, calls, total_exec_time, mean_exec_time
from pg_stat_statements
order by total_exec_time desc
limit 10;
-- 输出示例：
-- query                      | calls | mean_exec_time
-- select * from articles ... | 5021  | 182.34 ms
​

展开案例：用 Dashboard 救一次生产事故

背景：线上评论突然全不见了，用户在骂。运维只会用 Dashboard，不熟悉 psql。

操作过程：

1. 打开 Studio 的 Logs → Database，发现大量 permission denied for table comments 错误。
2. 怀疑是刚发版时一条 RLS 策略被误改（之前在 Dashboard 手动改过策略，没进迁移）。
3. 在 SQL Editor 里跑 select * from pg_policies where tablename='comments';，确认当前策略缺失 for select using (true)。
4. 补回策略并立即保存：

create policy "评论公开读"
  on public.comments for select
  using (true);
​

结果：几分钟内评论恢复可见，用户无感知到根因。

解读：Dashboard 的 Logs + SQL Editor 组合，让不熟悉命令行的同事也能快速定位和止血。但根因是"手动改策略没版本化"——事故后他们把这条策略补进了迁移文件，避免再犯。

变式：如果团队用 CI 自动 db push，手动在 Dashboard 改的策略会在下次 push 时被迁移覆盖，反而更安全。关键还是"一切结构走迁移"。

收尾提醒

• Dashboard 是操作后端的中控台，分区对应各底层组件。
• 它适合探索和止血，但结构必须落迁移文件版本化。
• Logs 和 SQL Editor 是排查生产问题的黄金组合。

提醒：在 Dashboard 手动改表结构/策略后，如果别人执行了 db push，你的改动会被迁移覆盖。团队务必约定"改结构只走迁移"，Dashboard 仅用于本地试验。

建议：我们建议给非技术的协作者（产品经理看数据、运营查用户）开只读权限的 Dashboard 账号，而不是把能改结构的账号给他们——可视化降低了门槛，也放大了误操作面。

Dashboard 能做的和不能做的：一张对照表

把"点界面"和"写代码"的能力边界划清，能少走很多弯路：

💡 关键直觉：Dashboard 是"人机的对话窗口"，代码是"机器之间的契约"。窗口适合探索、验证、止血；契约适合沉淀、评审、复现。凡是"下次还要再做一遍"的操作，都该从窗口里出来、变成契约。

再展开一个案例：把手动表结构反向落成迁移

背景：新手小队长在 Dashboard 里点出一张 tags 表（带两列），跑通了功能，但没写迁移。两周后新同事拉云端项目，本地 supabase start 起栈，发现根本没有这张表，功能直接崩。

操作过程：

1. 在 Dashboard 的 Table Editor 打开 tags，记下列名与类型。
2. 本地用 supabase migration new create_tags 生成迁移文件。
3. 把结构手写成 SQL 粘进迁移（等价于 Dashboard 点出来的 DDL）：

create table public.tags (
  id bigint generated always as identity primary key,
  name text not null unique,
  created_at timestamptz default now()
);
​

4. 本地 supabase db reset 应用迁移，确认和云端结构一致；再把迁移提交 Git。
5. 新同事 git pull 后 supabase start，表自动存在，功能不再崩。

结果：一次"界面探索"被固化为"可复现的迁移"，团队环境重新对齐。

解读：这步"反向落成迁移"是很多团队的必修课——先快速点出来验证想法，验证完立刻补迁移，别让结构躺在某个人的浏览器里。我们主张：任何进了生产的结构，48 小时内必须进迁移。

⚠️ 常见坑：Dashboard 里点的表和迁移里的表，列顺序、默认值、约束可能差一点（比如界面默认加了你没注意的索引）。补迁移后务必本地 db reset 校验，别想当然认为"长得一样"。

第二章我们把架构和组件讲完了。第三章进入动手环节：从建项目、写 CRUD、接认证，到实时、存储、函数，一节一个能跑的主题。