p.5方法⏱ 约 5 分钟

陷阱 #5:硬编码密钥与密码

一个 git push,密钥就公开泄露了

🔎 最后验证 2026-05📚 来源:《AI编程实战三卷书》卷三🧰 Claude Code、Git✅ 95 人学过👁 167 次阅读

为什么学这个

这是会让你真金白银损失的一类坑。AI 为了"能跑",常把 API Key、密码直接写死在代码里。你一提交、一推上 GitHub,密钥就对全世界公开了——爬虫几分钟内就能扫到并盗用。

💡 打个比方

把密钥写进代码再推上公开仓库,等于把家门钥匙复制一把贴在小区公告栏上,还标注了你家门牌号。再好的锁也没用了。

这个坑长什么样

// AI 图省事直接写死(❌ 危险):
const apiKey = "sk-1234real-secret-key5678";
fetch(url, { headers: { Authorization: apiKey } });
// 这行代码一旦被提交、推送到公开仓库 → 密钥泄露

为什么:写死最"省事、能立刻跑通",AI 默认选了最短路径
识别信号:代码里出现 sk-、password = "..."、token = "..." 这类明文机密;.env 没被 .gitignore 排除

密钥放进环境变量,代码里只读变量,不写明文:process.env.API_KEY
真实的密钥写在 .env 文件里,并用 .gitignore 排除它(永不提交)
⚠️ 关键:密钥只在"服务端"才真正安全。前端(浏览器里跑的)代码哪怕用环境变量,打包后也会暴露给用户——第三方密钥不能放前端,必须由你的后端持有、前端通过自己的后端转发请求。
提交前最好用自动扫描(如 git-secrets / gitleaks、平台的 secret scanning)兜底,别只靠肉眼"扫一眼"
万一已经推上去:立刻作废并重置该密钥(改回来也没用,历史里还在);注意私有仓库同样有风险(协作者、误转公开),硬编码本身就是问题

❓ 测验

API Key 正确的存放方式是?

⚠️ 避坑删掉再提交没用——Git 历史里它永远都在

很多人发现密钥提交了,就把它删掉再 commit,以为安全了。错! Git 会保留每一次历史,任何人翻历史都能看到那次提交里的密钥。一旦泄露,唯一正确的做法是立刻把那个密钥作废、换新的。这条认知能帮你避免重大损失。

🤖 让 AI 用安全方式处理密钥(收藏)

这段代码需要用到一个 API Key。请不要把密钥写死在代码里,改成从环境变量读取,并告诉我:1) 我该把真实密钥放在哪个文件;2) 怎么用 .gitignore 确保它不会被提交。

🔎 来源与核验· 1 条,点开核对

本节每个关键论断都对应一个可追溯的来源 —— 这是本课程"靠谱、不过时"的底线。

「密钥/密码不应硬编码;应使用环境变量并通过 .gitignore 排除敏感文件」

让 AI 写一段需要 API key / 密码的代码。

你会看到:它十有八九直接把 key 写死在代码里,一提交上 GitHub 就泄露。

怎么防:要求它「密钥一律从环境变量读」;提交前搜一遍有没有裸露的 key。

✅ 小结

密钥安全你守住了。还有一类安全坑藏在"怎么处理用户输入"里——下一节:注入类漏洞。

下一节 → 陷阱 #6:引入注入类安全漏洞

都看到这了，打个赏呗！