环境变量
Environment Variable也常被叫作：环境配置环境变量.env配置项env
「把「这个项目在不同机器上不一样的东西」单独拎出来存，比如数据库地址、密钥、端口。」
环境变量 Environment Variable
把代码里不该写死的配置（密钥、地址、端口）抽出来，按运行环境分别设置。
同一份代码，在你电脑上跑、在服务器上跑、在测试环境跑，要连的数据库、要用的密钥、监听的端口往往不一样。环境变量就是把这些「跑起来才知道的配置」从代码里拆出来、在运行环境里单独提供的一种做法。常见的形态是项目根目录一个 .env 文件，或部署平台的后台里填的一行行键值。
最大的风险点不是「用不用环境变量」，而是密钥别写进代码、别提交到仓库。写死的数据库密码、支付宝密钥如果进了 Git 仓库，等于把钥匙交给了所有能看仓库的人。.env 通常被加进忽略名单（.gitignore），让它别被提交。反过来，克隆到一台新机器时，你需要一个 .env.example 模板，让人知道该填哪些项。
还有一个容易踩的坑：改完 .env 里的配置，进程往往要重启才生效。很多 AI 改完环境变量就宣称「配置完成」，但服务没重启，或者密钥只放在本地、部署平台上根本没用上——于是线上连的还是一个坏地址或空密钥。判断环境变量有没有生效，得看它是否真的被这个跑着的进程读进去了。
长什么样 真实可交互，不是截图
# .env（本地，不会提交到仓库） DB_HOST=127.0.0.1 DB_PORT=5432 API_SECRET=sk-xxxx-not-a-real-key
# .env.example（给新人看的模板，可提交） DB_HOST= DB_PORT=5432 API_SECRET=
上面那行状态是环境变量最常见的翻车现场：本地 .env 配得好好的，线上平台那份是空的或旧的，于是本地能跑、线上报错。改完一定要在目标环境里确认读进去了。
拆开看，里面有这几块
-
1
键值对 Key / Value
一行一个配置，等号左边是名字（键），右边是值。
-
2
.env 文件 .env file
本地放配置的常用文件，通常不进版本库，密钥放这里。
-
3
.env.example Template
只写键、不写真值的模板，可提交到仓库，给队友照抄。
-
4
运行环境 Runtime env
服务实际运行时读到的配置。本地、测试、线上各有一套。
常见的有哪几种
开发时在项目根目录放一个，供本机进程读取。
用在：本地开发
在部署平台（如服务器、托管平台）后台填的配置，线上进程读它。
用在：线上 / 测试部署
操作系统层面设置，所有进程都可见。
用在：少数通用配置
容易搞混？这样区分
配置文件通常也是存在项目里的一份文件（如 config.js），但往往会随代码一起提交；环境变量则是「跑起来时注入」的，用来放不该进仓库的密钥和环境差异。敏感值放环境变量，公共配置放普通配置文件。
看 配置文件什么时候用得上
新机器克隆后启动失败，多半是少了 .env。用 .env.example 把键补齐。
本地正常、线上报错，先查线上平台的环境变量是不是空或旧地址。
把数据库密码、API 密钥挪到 .env，并确保 .gitignore 把它挡在仓库外。
你可以这样跟 AI 说
直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。
【任务】帮我把 [项目名] 的配置改成用环境变量管理 【范围】把数据库地址、端口、API 密钥这几项从写死的代码里抽出来，改用环境变量读取 【边界】 - 密钥这类敏感值不能写进代码，也不能出现在会提交到仓库的文件里 - 提供一个 .env.example 模板，只写键名不写真值 - 确保 .gitignore 把 .env 挡在版本库外，不要把它提交进去 - 不要改动业务逻辑，只改配置读取这一层 【交付】 1. 列出改了哪些文件、各放了哪些键 2. .env.example 的内容，以及 .gitignore 里加了哪一行 3. 告诉我服务要怎么重启、在哪个环境读哪些配置才生效 4. 实测：改一个值后，服务是否读到了新值
这段专门堵了两个高频翻车点：密钥有没有进仓库、改完有没有真的重启生效。第 4 条要求「改值后实测读到新值」，防止只改文件不算数。
它说「做好了」，你怎么自己验
这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「运行时」这层：真的跑起来了，能在本机看到结果。
要亲眼看到这些，才算数
- 打开代码，确认数据库地址、密钥这些值不是硬编码在业务文件里，而是来自环境变量读取。
- 确认仓库里存在 .env.example（只有键名），且 .gitignore 里有 .env，
git status不会把它列进来。 - 改一个环境变量的值（比如改数据库地址），重启服务，看日志/连接是否用了新值——证明它真的被读进去了。
- 在部署平台上检查线上那套环境变量，确认键都填了、值不是空或残留旧的。
- 确认密钥不会出现在日志、报错信息或前端代码里（本地前端能直接看到的不算环境变量该藏的东西）。
它常这么糊弄你
- 「环境变量已配置」——但只是写了个 .env 文件，服务没重启，根本没读。改完要重启并实测。
- 「密钥已放到环境变量」——但 .env 没加进 .gitignore，还是会被提交进仓库。查
git status。 - 「线上已配置」——但只在本地 .env 里改了，线上平台那套还是空的或旧的。要分别检查线上。
- 「配置完成」——但数据库地址或密钥还硬编码在代码里，环境变量只是个摆设。打开代码验证读取来源。
环境变量这类配置任务最高能验到「运行时」层：改一个值、重启、确认读到新值，就证明配置真的生效了。要往「生产」层走，还需要密钥轮换、权限隔离、审计，那不是第一轮的重点。
考考你 选一个你觉得对的
AI 说「环境变量已经配好了，密钥放进 .env 了」。你担心密钥还是会被泄露，最该检查什么？
密钥进仓库是泄露的第一大来源。光「放进 .env」不够，得确认 .env 没被 Git 跟踪（.gitignore + git status），否则克隆出去的人都能看到。