API Key 和环境变量怎么放，泄露以后先做什么？
让私密凭据只在受保护的服务端使用，区分本地和线上配置，并按吊销、替换、追查处理泄露。
本页目录
直接回答
私密 API Key 是调用服务的凭据，应由受保护的服务端读取，不能写进前端代码、公开仓库或普通聊天记录。Next.js 官方文档确认 NEXT_PUBLIC_ 前缀会让相关值进入浏览器代码，因此它适合公开配置，不适合私密 Key。环境变量只是配置途径，并不自动提供所有保护：如果接口把它返回给浏览器，或日志打印了它，仍然会暴露。不应要求 AI 输出沙箱内部凭据，应通过服务商支持且获授权的方式获取自己的凭据。
适用场景
- 准备连接模型、数据库、对象存储或邮件服务
- 本地正常，线上提示缺少环境变量
- 误把 Key 放进代码、截图、日志或 Git 历史
一步一步做
列出配置并区分公开与私密
只记录变量名称、用途和所属服务，不在需求文档填真实值。公开 Site Key、网站 ID 与私密 Secret Key、数据库密码用途不同。按实际业务分开发、测试和生产配置，权限仅满足所需操作。
在正确环境配置自己的凭据
本地按框架约定配置；Next.js 的 .env 文件放在项目根目录，而非 src 内。线上在部署平台相应环境配置，不能假设本地文件自动上传。修改后按平台要求重启或重新部署，再通过实际业务验证。
让浏览器只调用自己的受保护接口
服务端先验证输入、身份和额度，再读取 Key 调用供应商。只返回业务所需结果，不把完整上游配置一起传回页面。整理建议：没有身份或额度保护的服务端转发，仍可能被其他人用来消耗你的 API。
检查常见泄露位置
检查待提交文件、历史记录、前端产物、网络请求、日志和截图。忽略规则只能阻止某些后续文件被加入，不能抹去已经提交的历史。共享排错材料时使用变量名、请求 ID 和脱敏片段，不复制全部环境变量。
泄露后先让旧凭据失效
一旦确认或有依据怀疑泄露，按服务商流程吊销旧凭据、创建权限合适的新凭据，更新实际使用环境并验证。再检查调用记录与账单、清理暴露位置。需要改写 Git 历史时应先协调协作伙伴和保全工作，不能把强推当成通用第一步。
案例拆解
假设示例：把 Key 改名并不能修复泄露
某页面曾直接引用 NEXT_PUBLIC_MODEL_KEY，后来开发者把变量名改成 MODEL_KEY 并从源码删除旧值。若旧网页代码或 Git 提交仍含原 Key，它仍可能被使用。正确处理是让旧 Key 失效，配置新 Key 到服务端，检查接口是否需要认证和限额，再验证前端代码与返回值都不包含新凭据。
行动检查
可复制模板
凭据配置检查表
工作模板
变量名：［不填真实值］
所属服务与用途：［描述］
公开／私密：［选择］
运行环境：［本地／预览／生产］
读取位置：［服务端文件或平台配置］
最小权限：［实际需要的操作］
验证：［真实功能与脱敏日志］
轮换影响：［哪些环境需要更新］
请只报告配置是否存在和权限是否合适，不输出凭据本身。
易错点
- 认为写进 .env 就一定安全：还要检查 Git、部署、日志和返回内容。
- 用 NEXT_PUBLIC_ 修复浏览器读不到密钥的问题：这会把秘密公开。
- 先清历史再吊销：清理文件不能让已经被复制的凭据失效。
相关指南
官方参考
-
Next.js：Environment Variables — 说明公开变量进入浏览器构建、本地文件位置与构建时固定值 资料核查记录日期：2026-10-18。
-
OWASP：Secrets Management — 说明最小权限、秘密生命周期与暴露后立即吊销原则 资料核查记录日期：2026-10-18。