环境变量让配置和代码分离，但它不是自动生效的保险箱。一个值是否保密，取决于它在哪里被读取、是否进入构建结果，以及最终发送给了谁。
先区分两类配置
公开配置可以被访客看到，例如站点名称、公开域名和前端可使用的公开标识。
服务端密钥包括模型服务的 API Key、数据库密码、签名密钥等。这类信息只能在可信的服务端环境使用，不能发送给浏览器。
在 Astro 中，PUBLIC_ 前缀表示允许在客户端使用。不要用它保存密钥。
# 可以公开的示例配置
PUBLIC_SITE_NAME=AICookCode
# 仅供具备服务端能力的应用使用，不应进入客户端
MODEL_API_KEY=replace_with_your_own_key变量名没有 PUBLIC_ 也不意味着绝对不会泄漏。如果服务端把值写进 HTML、日志或 API 响应，访客依然可能读到它。
本地文件不要提交
在 .gitignore 中排除环境文件，同时允许提交仅包含占位值的示例：
.env
.env.*
!.env.example.gitignore 只影响尚未跟踪的文件。已经被 Git 跟踪的文件不会因为新增规则而自动从历史消失。
提交前检查暂存区：
git status
git diff --staged密钥也可能出现在截图、调试输出、请求示例和错误日志里。检查时不要只盯着 .env。
静态构建与服务端运行不同
静态站点在构建时生成文件，访客访问的是这些已经生成的 HTML、CSS 和 JavaScript。构建环境变量不会自动变成一个运行时服务端接口。
如果你在静态页面里使用密钥生成内容，仍要检查最终产物是否包含密钥或不该公开的数据。
本站只是静态博客，本身不需要模型密钥。未来如果要做 AI 工具，可以单独部署 API 服务，并在对应平台的服务端密钥设置中配置凭据。
云端分别设置环境
正式环境和预览环境最好使用不同的凭据与额度。预览部署的访问范围可能不同，也更容易运行尚未验证的代码。
在托管平台设置变量后，根据平台要求重新部署。不要假设修改配置后，已经生成的静态文件会自动变化。
构建日志只记录必要状态。不要通过打印全部环境变量来排查配置问题，可以只输出「配置是否存在」这样的布尔值。
发现泄漏时，先撤销密钥
如果密钥已经进入公开仓库，第一步是在服务提供方撤销或轮换它，并检查异常用量。仅删除最新版本中的字符串，无法让已经复制出去的密钥失效。
后续再根据仓库情况处理历史记录、缓存和其他引用。重写共享仓库历史会影响协作者，应协调完成。
公开配置、构建配置、运行时密钥，三者各有位置。把这条边界想清楚，比记住某一种文件命名方式更有用。
参考：Astro 环境变量 · GitHub 移除敏感数据
