数据库与后端：Supabase / 云数据库 / Serverless 怎么接

你的站做到现在，可能开始有这种需求了：用户要能注册登录、提交的内容要存下来、调用某个付费 API 的密钥不能让人看到。这些都需要一个"后端"——可你是一个人，没精力去搭一整套服务器、装数据库、写一堆后端框架。这一节就讲一人开发怎么用最省力的方式，给你的产品接上后端和数据库，而不是为此搭一个能扛百万用户的庞然大物。

这篇适合谁：你的前端站已经能部署上线（前两节部署上线、域名 HTTPS DNS讲过了），现在想加"存数据、登录、保密钥"的能力，但一听 "后端""数据库" 就觉得是另一个世界的事。读完你会理清几种省力方案各适合什么，并搞懂数据是怎么从前端流到数据库的、密钥该藏在哪。

---

先建立一个心智模型：数据是怎么流动的

讲方案之前，先把一张图刻进脑子。一个带后端的应用，数据流通常是这样：

用户的浏览器（前端）
      ↓  发请求
Serverless 函数 / 后端（藏密钥、做校验）
      ↓  查/存
数据库（真正存数据的地方）

为什么中间要夹一层后端/函数，前端不能直接连数据库？ 因为前端代码是完全公开的——任何用户按 F12 都能看到。如果你把数据库密码写在前端，等于把家门钥匙贴在门上。所以敏感操作和密钥必须放在用户看不到的那一层（Serverless 函数或后端）里执行。

记住这个分工：前端负责显示和交互，后端/函数负责"持密钥、做判断、读写数据库"，数据库负责存。 下面的几种方案，本质都是在帮你用最少的力气搭出中间和右边这两块。

---

三种省力方案，分别适合什么

Supabase：最适合快速起步的"开箱后端"

Supabase 是一个托管的后端服务，把数据库（Postgres）、用户鉴权（登录注册）、文件存储打包成一套，给你现成的接口直接调。 它的卖点是：你不用自己装数据库、不用写登录逻辑，注册个项目，它就给你一个能用的后端。

适合谁：一个人想快速给产品加"登录 + 存数据 + 传文件"，又不想搭服务器的。它自带的鉴权能省掉你自己写一套登录系统的大工程——这块自己写既费时又容易出安全漏洞。

它的妙处在于：简单读写可以从前端直接调（靠它的"行级安全"规则在数据库层把权限管住），复杂或敏感的逻辑再放到函数里。对 MVP 来说，上手成本是这几种里最低的。

云数据库：你只要一个"放数据的地方"

如果你已经有自己的后端代码，只缺一个存数据的库，那就用云厂商的托管数据库——阿里云、腾讯云、AWS 等都提供托管的 Postgres、MySQL、MongoDB 等。你不用自己运维数据库服务器，厂商帮你管备份、扩容、安全更新，你拿到一个连接地址就能用。

适合谁：你的后端逻辑想自己掌控（比如已经在自有服务器或某个后端框架上跑了），只需要一个可靠的数据库。比起在自己服务器上手装数据库，托管云数据库省掉了运维这块大头。

Serverless 函数：按需运行的"无服务器后端"

Serverless 函数就是一段后端代码，你不用管它跑在哪台服务器上——平台在有请求时才临时拉起来执行，跑完就放下。 Vercel、Netlify、Cloudflare 都内置了这能力，你在项目里写一个函数文件，部署后它就有了一个可调用的网址。

适合谁：你只是想要"几个零散的后端接口"——比如一个处理表单的、一个代调第三方 API 藏密钥的、一个做支付回调的——而不想为此养一台一直开着的服务器。它和前端平台天然集成，前端发请求过去就行。

它最适合干的活：当那个"藏密钥的中间层"。前端不方便直接暴露的密钥，就放进 Serverless 函数里调用。

三者关系常常是组合的：很多人用 Supabase 存数据 + Serverless 函数处理敏感逻辑，前端平台一键部署，整套零运维。

---

增量一：后端方案选型表

方案	最适合	上手成本	主要的坑
Supabase	一人快速加"数据库+登录+存储"，MVP 起步	低，开箱即用	行级安全规则要配对，配错了数据可能裸奔；免费额度有上限
云数据库	已有后端、只缺一个托管数据库	中，要会连接和基本运维概念	连接数有上限；要管好访问白名单和密码
Serverless 函数	几个零散后端接口、藏密钥、表单/回调	低到中，写函数文件即可	冷启动延迟；执行时长有限制，不适合长任务

各方案的具体额度、连接数上限、函数时长限制经常变，以官方文档为准，别背某篇旧文里的数字。

---

走一遍最小数据流：前端 → 函数 → 数据库

用最常见的组合演示思路（具体接口写法以各家官方为准，这里讲的是不变的机制）。假设你要做一个"提交留言并存起来"的功能。

第一步：在数据库里建一张表

不管用 Supabase 还是云数据库，先有个地方存。在 Supabase 里，你在它后台新建一张 messages 表，几个字段：id、content、created_at。

你应该看到什么：表建好后，后台能看到这张空表的结构。这就是数据最终落脚的地方。

第二步：写一个 Serverless 函数接收提交

在你的项目里建一个函数文件（路径规则各平台不同，以官方为准），逻辑大致是：

// 伪代码示意，真实写法以你用的平台/库官方文档为准
export default async function handler(req, res) {
  // 1. 从前端发来的请求里取出留言内容
  const { content } = req.body;

  // 2. 用环境变量里的密钥连数据库（密钥绝不写死在这里）
  const dbKey = process.env.SUPABASE_SERVICE_KEY;

  // 3. 把内容存进数据库的 messages 表
  // ...调用数据库客户端，插入一条记录...

  // 4. 告诉前端：存好了
  res.status(200).json({ ok: true });
}

注意第 2 步：密钥是从 process.env 读的，没有任何一处把真实密钥字符串写在代码里。 这是这一节最重要的安全习惯，下面专门讲。

第三步：前端把数据发给这个函数

前端不直接碰数据库，而是发请求给你这个函数的网址：

// 前端代码（会被用户看到，所以这里没有任何密钥）
await fetch('/api/submit-message', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ content: '我的留言' }),
});

你应该看到什么：提交后，回到数据库后台刷新 messages 表，能看到刚才那条留言被存进去了。整条链路就打通了：前端发请求 → 函数持密钥连库 → 数据落表。

这个最小例子虽小，但骨架是通用的：以后做登录、做支付、做任何"前端不能直接干"的事，都是这个结构——敏感的活塞进中间那层函数，密钥放环境变量。

---

关键安全习惯：密钥放环境变量，别硬编码

这条单独拎出来强调，因为它是新手翻车的重灾区。

绝不能把数据库密码、API 密钥这类东西直接写在代码里然后推到 git 仓库。 一旦推上去，哪怕你后来删了，git 历史里还留着；如果仓库是公开的，几分钟内就可能被扫库的机器人捡走盗用。

正确做法（和部署上线那节配环境变量是同一套）：

1. 本地开发时，密钥放在项目根目录的 .env 文件里，并把 .env 写进 .gitignore，确保它永远不进 git。
2. 代码里用 process.env.你的变量名 来读，而不是写死字符串。
3. 部署到平台时，在平台的"环境变量"设置里把这些密钥一条条加进去。

还有一个 Supabase 特有的点：它有两种密钥——一个能放前端的"匿名公钥"（受行级安全规则保护），一个绝不能给前端的"服务密钥"（权限极大）。服务密钥只能用在 Serverless 函数/后端里。 别把这俩搞混，搞混了等于数据库门户大开。具体哪个是哪个以 Supabase 官方文档为准。

---

怎么不被上线后才暴露的坑坑到

本地一个人测的时候一切正常，一上线来了真用户，问题才冒出来。提前知道这几个：

连接数爆

数据库能同时接受的连接是有上限的。Serverless 函数有个陷阱：每次请求可能拉起一个新实例、各自开一个数据库连接，流量一大，连接数瞬间就爆了，数据库开始拒绝服务。

破解思路：用连接池（connection pooling）——让一个中间层管理一批可复用的连接，函数们共享，而不是各开各的。Supabase 和主流云数据库都提供连接池方案，用它们给的"池化连接地址"而不是直连地址。具体怎么开以官方文档为准。

密钥泄露

前面讲过了，这里再钉一遍：密钥进了 git 历史就当它已经泄露。真不小心推上去了，第一时间去对应平台作废旧密钥、生成新的，光删代码没用。

冷启动慢

Serverless 函数"用时才拉起"省钱，但代价是：如果一段时间没人调，下次第一个请求要等它冷启动，可能慢个一两秒。对偶尔用的接口无所谓，对要求"点了立刻响应"的核心路径，这个延迟用户能感觉到。

破解思路：核心接口可以用平台的"保持温热"机制（各家叫法不同，以官方为准），或把对延迟敏感的逻辑换成常驻后端。MVP 阶段一般先忍着，等真有用户抱怨了再优化。

---

增量二：数据库上线前 checklist

接后端、要上线前，对着过一遍：

• 连接：用的是连接池/池化地址，不是会被流量打爆的直连地址
• 密钥：所有密钥走环境变量，代码里零硬编码，.env 在 .gitignore 里
• 公私钥分清：前端只用匿名/公钥，服务密钥只在函数/后端里
• 权限规则：Supabase 的行级安全规则配好了，数据没裸奔（默认拒绝、按需放开）
• 备份：确认数据库自动备份开着，知道怎么恢复
• 冷启动：核心接口的响应延迟测过，能接受
• 额度：免费额度上限心里有数，知道什么量级会触顶

---

故障排查：后端出问题时照这张表查

现象	最可能的原因	怎么办
流量一大数据库报"too many connections"	函数各开各的连接，连接数爆	改用连接池/池化连接地址，别用直连
接口报"密钥无效"/权限不足	环境变量没配、配错、或用错了公私钥	核对平台环境变量；分清匿名钥和服务钥用在哪
第一个请求很慢，之后就快了	Serverless 冷启动	正常现象；核心接口考虑保温机制或常驻后端
前端能看到数据库密钥	密钥被硬编码进了前端代码	立刻作废该密钥重新生成，把读取改为后端经环境变量
数据能被任意用户读写	行级安全规则没配/全开	设为默认拒绝，按角色/所有权精细放开
函数跑到一半超时被掐	任务超过了 Serverless 执行时长上限	长任务拆短、异步化，或改用常驻后端处理

最该刻进肌肉记忆的两条：密钥进 git 当泄露处理、立刻换；连接一定走池化。 这两条能帮你躲掉上线后最惊险的两类事故。

---

动手挑战

1. 用 Supabase 建一张表，写一个 Serverless 函数接收前端提交并存进去，跑通"前端 → 函数 → 数据库"这条最小链路，亲眼看到数据落表。
2. 把一个密钥故意只放在环境变量里，本地用 .env、线上用平台变量，确认两处都能正常读到、而代码里一个明文密钥都没有。
3. 进阶：查一下你所用数据库/平台的连接数上限和函数时长限制（以官方文档为准），写在你的项目笔记里，做到心里有底。

---

小结 · 你现在掌握了什么

• 你能看懂 Supabase、云数据库、Serverless 函数各自适合什么，一个人起步该怎么组合最省力。
• 你理清了"前端 → 函数 → 数据库"的数据流，明白为什么密钥必须藏在用户看不到的那层。
• 你养成了"密钥走环境变量、绝不硬编码"的习惯，也提前知道了连接数爆、冷启动慢这些上线后才暴露的坑，并有一份 checklist 防着。

后端和数据库一接上，你的产品就从"能看"进化到"能用、能记住用户"。这一步跨过去，它才算一个真正能留住人的产品，而不只是个演示页。

下一步：部署、域名、后端这三块——也就是本级上线与运营的核心——都齐了，你的 MVP 已经是个真用户能用的产品。接下来该回到产品本身去打磨和迭代；想看自己在整条路上的位置，对照三支柱路线图。

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。