发布上线前必读
模块 5 · 第 1 节
密钥与凭证安全：API Key 绝对不能进公开仓库
是什么
API 密钥、数据库密码这类凭证，是你的应用连接外部服务的"钥匙"。一旦它们被意外公开——比如被推送到了公开的代码仓库——几分钟之内就会被自动爬虫抓走，然后被盗用产生巨额损失。
解决什么问题
如果不了解密钥安全的重要性，你可能会把密钥直接写在代码里并推送到公开仓库。这些密钥会在数分钟内被网络上的自动扫描程序发现，导致你的云服务账户被盗刷。
钥匙和代码，绝不能混装
当你的应用需要连接外部服务时——比如调用 AI 接口、连接数据库、使用支付系统——这些服务会给你一串字符，通常叫做 API Key、Secret Key 或 Token。
这串字符就是你的"钥匙"。拿着它，任何人都可以以你的身份使用这些服务——包括产生费用。
现在想象一下：你把这把钥匙直接写在了代码里，然后把代码推送到了公开的 GitHub 仓库。
这就相当于你把家门钥匙挂在了广场上的公告栏上。
几分钟，仅仅几分钟
你可能会想："我的仓库又没什么人关注，谁会去翻我的代码？"
事实是：不是人在翻你的代码，是机器人。
互联网上有大量的自动扫描程序，它们 24 小时不间断地监控 GitHub 上每一次新的代码推送，专门搜索长得像密钥的字符串。一旦发现，它们会自动尝试使用这些密钥。
从密钥被推送到公开仓库，到被扫描程序发现，通常只需要几分钟。然后，你的云服务账户就会开始被不明来源的请求疯狂调用。等你第二天早上醒来查看邮件，可能已经收到了一封数百甚至数千美元的账单。
这不是假设的情景，这是开发者社区中反复发生的真实事件。
密钥一旦进了公开仓库，就视同已泄露
不要抱有"没人会注意到我的小仓库"的侥幸心理。自动扫描程序不分昼夜地监控每一次推送，从推送到被窃用通常仅需几分钟。一旦密钥进入公开仓库，唯一正确的动作是立即吊销并生成新密钥——而不是删除代码后当作没发生。
正确的做法：用环境变量
密钥不应该出现在代码文件中。它们应该被放在环境变量里。
具体来说：
在项目中创建一个 .env 文件。 这个文件专门用来存放密钥和其他敏感配置。比如：
DATABASE_URL=你的数据库连接地址
API_KEY=你的API密钥在代码中通过环境变量读取。 代码里不再写死密钥的值，而是写成类似 process.env.API_KEY 的形式——意思是"去环境变量里找叫 API_KEY 的那个值"。
确保 .env 文件不会被推送到仓库。 项目中的 .gitignore 文件会列出哪些文件不应该被 Git 追踪。确认 .env 在这个列表中。
部署时在平台上单独配置。 当你把项目部署到 Vercel、Railway 等平台时，这些平台都提供了专门的界面来设置环境变量——你在那里填入密钥的值，它们会被安全地存储，不会出现在代码中。
如果密钥已经泄露了
如果你发现密钥已经被推送到了公开仓库，不要抱侥幸心理，应该立即行动：
泄露应急四步
第一步：吊销旧密钥。 登录对应的服务平台，找到密钥管理页面，把泄露的那个密钥作废（revoke 或 delete）。
第二步：生成新密钥。 在同一个页面生成一个新的密钥。
第三步：更新你的环境变量。 把新密钥填入你本地的 .env 文件和部署平台的环境变量配置中。
第四步：从 Git 历史中清除。 即使你已经从最新的代码中删除了密钥，它仍然存在于 Git 的提交历史中。既然密钥已经被吊销，历史中的旧密钥已经无法使用，安全风险就已经解除了。
整个过程不到十分钟，但能避免潜在的巨额损失。
一条简单的规则
如果你只记住一条关于安全的规则，请记住这条：
任何看起来像密码、密钥、Token 的东西，都不应该直接出现在代码文件里。
每次 AI 帮你接入外部服务时，检查一下它有没有把密钥直接写在代码中。如果有，告诉它改用环境变量。这个检查只需要几秒钟，却能帮你守住最基本的安全底线。
指挥与验收
一边讲怎么让 AI 帮你做，一边讲怎么看出 AI 做砸了。
指挥
连接到
术语
事故复盘