参考卡 · 配套 2.5 部署全栈 + 密钥安全 · 可反复回看 / 可打印

密钥安全小卡

这是整门课里唯一一件做错了会真出事的事。别的地方搞砸了最多是页面难看、功能不好使，钥匙漏了是数据库被人拖走、账单被刷爆。这张卡值得单独存一份——以后每接一个新服务、每部署一次，都回来对一遍。

1. 两把钥匙，一把能公开，一把打死不能露

前台钥匙 · 可以公开

新项目叫 Publishable key(值以 sb_publishable_ 开头)；老项目叫 anon。

这把是给网页用的，它出现在前端、被人看到，也不要紧。

为什么不怕？因为数据库门口有 RLS 规则把着，别人就算拿到这把，也只能干"规则允许的事"（比如注册、看自己的），动不了别人的数据。

万能钥匙 · 绝对保密

新项目叫 Secret key(值以 sb_secret_ 开头)；老项目叫 service_role。

这把能绕过所有规则、动所有人的数据。

绝对不能出现在网页里、不能提交到 GitHub、不能发给任何人、不能贴进任何聊天框。它漏出去，等于把整个数据库的大门钥匙贴到了大街上。

为什么会有两套名字：Supabase 换过一次命名，新旧两套一一对应、规矩完全一样——sb_publishable_ ≙ anon(能公开)，sb_secret_ ≙ service_role(打死不能露)。老的两个名字官方计划 2026 年底停用。认作用，别认位置：能给网页用的那把可以公开，能绕过规则动所有数据的那把不能。拿不准就去 Settings → API Keys 看，或对照官方 API Keys 说明页。

2. 五条规矩

钥匙不写死在代码里，放环境变量（本地放 .env，线上填到托管平台的环境变量设置里）。
.env 一定要在 .gitignore 名单里，不进代码仓库。.gitignore 就是一份"这些文件别提交"的清单，放在项目根目录。
万能钥匙（sb_secret_ / service_role）只在后端用，绝不进前端、不进 GitHub、不发群里。
不小心提交了 → 当作已经泄露 → 立刻去平台后台把它作废、重发一把，再把新钥匙填回环境变量。哪怕你马上删掉了那次提交也一样——Git 里删掉不等于没存在过。
不确定某样东西能不能公开？先当成不能，去问你的 Agent："这个贴到前端／GitHub 安全吗？"

这不是吓唬人。网上有机器人 7×24 小时专门扫 GitHub 上不小心提交的密钥。一把万能钥匙被扫到，几分钟内你的数据库就可能被人拖走、清空，或者被拿去干坏事、给你刷出天价账单。

3. 每次部署前，照着问 Agent 一遍

部署前三条检查 · 原样发给 Agent

我要部署了。帮我检查一遍：
1. 我的密钥有没有写死在代码里？有的话挪到环境变量。
2. .env 有没有在 .gitignore 里、确保不会被提交到 GitHub？
3. 万能钥匙（sb_secret_ 或 service_role 那把）有没有不小心出现在前端代码里？
逐条告诉我检查结果。

4. 部署完，自己去 GitHub 搜一次

别只信 Agent 说"检查过了"。打开你项目的 GitHub 仓库，用仓库搜索框搜一下你的钥匙（尤其 sb_secret_ / service_role 那串）。

翻不到 —— 才算安心。
万一翻到了 —— 立刻回平台作废重发，按第 4 条走。

这一步是这张卡上唯一一条你能自己判定真假的检查：结果是二元的，搜得到或搜不到，不用信任何人的说法。养成部署完顺手搜一次的习惯。

5. 什么时候翻这张卡

第一次拿到某个服务的 key，不确定哪把能公开
准备把项目推到 GitHub 之前
准备部署上线之前
怀疑自己把 key 贴到了不该贴的地方（聊天框、截图、群里）
换新服务、换新平台、开新项目——每一次都值得再过一遍

拿不准某样东西能不能公开？别自己硬猜。把情况发到群里，或直接找 Abel、助教。钥匙安全这事，宁可多问一句。