研路炼钢 | 我把 Vercel、Supabase 和 Surge 都连上了，但这还不叫工作流

这两天，我把 Vercel、Supabase 和 Surge 依次接进了自己的工具箱。

Vercel 能看见项目，博客页面实际返回了 200；Supabase 能读到组织和两个项目；Surge 能列出五个站点，五个地址也都能正常打开。

如果只看仪表盘，这已经是一片绿灯。

但我很快意识到：三个工具都能用，不等于三个工具已经一起工作。

登录成功，只能证明钥匙是真的；页面能开，只能证明炉子还热着。真正的工作流，必须让一块原料从入口进炉，经过加工、落库、验收，再带着证据回到我手里。

01｜三个工具都亮了绿灯

先说现场。

Vercel 这边，连接器能正常读取账号下的项目，博客部署也能直接访问。我请求线上页面，拿到的是 200，页面标题也和预期一致。

Supabase 这边，组织与项目列表可以正常读取。两个现有项目分别在东京和新加坡，只是当时都处于暂停状态。这个结果至少说明：账号、权限和管理通道是通的；要进入业务链路，还需要先恢复目标项目。

Surge 更直接。命令行列出了五个站点：

• linkable-board.surge.sh
• aidatabase-squ.surge.sh
• aidatabase-zhangxin.surge.sh
• aidatabase-insistgang.surge.sh
• insistgang-test2.surge.sh

我又逐个发起请求，五个站点都返回了 200。

这轮检查有价值，但它只完成了设备点检。三台机器各自转起来了，传送带还没有接上。

02｜能登录、能访问、能完成，是三件事

我现在会把“跑通”拆成三层。

第一层是身份可达：账号能登录、令牌有效、插件能读到资源。

第二层是服务可达：域名能解析、页面能打开、接口能返回明确的状态码。

第三层才是业务完成：页面发起真实请求，后端处理成功，数据库产生预期记录，用户拿到正确结果，而且日志能把整段过程串起来。

这次 Surge 还给了我一个很典型的提醒。

在一个受限执行环境里，命令行曾因为无法写入凭据文件而报错；但用户自己的终端已经成功执行 surge list，线上站点也全部能访问。问题不在 Surge 服务，而在观察它的那间“检测室”权限不足。

排障最怕把观察环境的故障，误判成生产设备的故障。

所以从现在开始，我不再用一句“连不上”概括所有问题。我会先问：是身份没通过，网络没到达，还是业务没有完成？

03｜真正的链路：Surge → Vercel → Supabase

这三个工具组合起来，最清晰的分工不是互相替代，而是各守一道工序。

Surge 负责静态入口。它适合快速发布演示页、管理台外壳和轻量前端，让用户先拿到一个稳定可访问的界面。

Vercel 负责服务接口。浏览器把请求交给 Vercel 函数，由它校验参数、执行业务逻辑、读取环境变量，再去访问数据库。

Supabase 负责数据底座。表、权限策略、身份认证和持久化记录都留在这里。

最小闭环可以很小：

用户打开静态页面
  → 页面请求服务接口
  → 服务接口查询云端数据库
  → 数据库返回一条记录
  → 服务接口返回结构化结果
  → 页面显示结果与请求编号

这里最重要的一条红线是：数据库的高权限密钥不能放进 Surge 的前端代码。

浏览器里发布出去的内容，本质上都应视为公开。需要保密的凭据必须留在 Vercel 的服务端环境变量里；Supabase 再用行级安全策略限制每个身份能读写什么。

这条链路不是为了把架构画复杂，而是为了把边界焊牢。

04｜SOP 不是步骤清单，而是一条证据链

过去我写 SOP，容易写成“先点这里，再运行那里”。这样的文档能指导操作，却不能证明结果。

真正可复用的 SOP，每一步都要带一个验收件：

工序	操作	验收证据
静态入口	发布 Surge 页面	固定地址返回 200，页面版本号正确
服务接口	部署 Vercel 函数	健康检查返回 200，响应带请求编号
数据访问	查询或写入 Supabase	目标表出现预期记录，时间与请求编号一致
前端回显	展示业务结果	页面内容与数据库记录一致
现场留痕	保存日志与版本	能从请求编号追到部署、日志和数据记录

这套 SOP 的结束条件也必须写死：

不是“我操作完了”，而是“结果已验证、证据已保存、下一次可以复现”。

如果没有请求编号，前端截图、函数日志和数据库记录就像散落在车间里的三张纸；一旦出错，很难证明它们属于同一炉钢。

让证据共享同一个编号，排障才会从猜测变成追踪。

05｜回滚能力，才决定这套系统敢不敢用

一条只能向前冲的流水线，不叫自动化，叫风险放大器。

Vercel 的价值不只是发布快，还在于可以先生成预览部署。新接口先在预览环境验证，通过后再进入生产；生产版本出问题时，要能立即切回上一份可用部署。

Surge 发布前要保留明确的版本标记。新页面如果异常，应该能快速恢复上一版静态产物，而不是现场重新打包、重新猜。

Supabase 更要克制。结构变更先备份，再做可审查的迁移；新增字段优先于直接删除；权限策略先在测试身份下验证；任何高权限密钥都不进入前端，也不进入仓库。

我给这套链路设了四个放行条件：

1. 预览环境已经跑完一次真实请求；
2. 数据变更有备份或可逆迁移；
3. 三层证据能用同一个请求编号串起来；
4. 回滚动作已经写清楚，并且真的演练过。

能部署，只代表油门存在；能回滚，才代表刹车存在。

写在最后

这次最有价值的，不是又多装了三个工具。

而是我终于把“已连接”与“已完成”分开了：Vercel、Supabase、Surge 各自在线，只是零件验收；一次请求从静态入口出发，穿过服务接口，命中数据库，再带着编号、日志和结果回来，才算整条产线交付。

下一步也很明确：恢复目标 Supabase 项目，建立一张最小测试表，在 Vercel 写一个健康检查接口，再让 Surge 页面完成一次真实读写。跑通以后，把请求编号、验收证据和回滚动作固化成模板。

别再问工具装没装。

让一次请求走完，拿回证据。