用 Codex 修改项目时，经常会遇到一种情况：

.env 明明已经改了，但项目启动后还是读取不到新配置。

常见表现包括：

• 环境变量已经写入，程序仍提示缺失；

• 修改 .env 后服务行为完全没变化；

• 本地正常，CI或Docker里却报错；

• 同一个变量在不同环境读取到不同值；

• Codex改了配置文件，但真正运行环境没有生效。

这类问题很多时候不是业务代码错误，而是：

配置文件、加载顺序和实际运行环境没有对应上。

一、先确认程序到底读取哪个 .env

很多项目并不只有一个环境文件。

例如：

.env
.env.local
.env.development
.env.test
.env.production

你修改了：

.env

但当前开发环境真正优先读取的可能是：

.env.local

这时候 .env 里的新值就可能被覆盖。

所以第一步不是继续改变量，而是确认：

当前项目实际加载的是哪个配置文件。

---

二、检查变量名称是否完全一致

例如代码读取：

DATABASE_URL

但配置文件写成：

DATABASE_URI

看起来非常接近，程序实际上完全读取不到。

还要注意：

• 大小写；

• 下划线；

• 前缀；

• 拼写。

特别是前端项目，有些框架要求环境变量使用特定前缀。

如果命名不符合规则，即使 .env 里存在，也未必能够直接使用。

---

三、修改 .env 后可能需要重启服务

很多开发服务器只会在启动时读取环境变量。

例如你修改：

API_URL

但服务已经运行了半小时。

此时刷新页面不一定会重新加载配置。

可以尝试：

停止服务
↓
重新启动
↓
再次验证

所以遇到：

文件已经改了，但程序行为没有变化

先不要急着怀疑代码。

确认服务是否真正重新加载过配置。

---

四、本地终端和Codex运行环境可能不同

你自己的终端里可能已经存在：

API_KEY
DATABASE_URL
NODE_ENV

这些变量甚至可能不是从 .env 读取，而是系统环境提前设置好的。

Codex运行命令的环境却未必拥有同样配置。

于是会出现：

开发者本地正常，Agent执行失败。

这时候应该对比：

• 当前Shell环境；

• .env 文件；

• 系统环境变量；

• 项目启动脚本。

不要默认两边环境完全一致。

---

五、Docker里的 .env 不一定就是应用读取的 .env

如果项目运行在Docker里，配置链路可能更复杂。

例如：

宿主机.env
↓
docker compose
↓
容器环境变量
↓
应用程序

你只修改宿主机文件，并不一定意味着正在运行的容器已经更新。

可能需要：

• 重新创建容器；

• 检查Compose配置；

• 确认变量是否真正传入容器。

所以Docker环境里，更应该关注：

应用最终读取到什么值。

而不是只看宿主机文件有没有修改。

---

六、CI环境通常不会自动读取你的本地 .env

本地测试通过，但CI提示：

Missing API_KEY

并不奇怪。

因为 .env 往往不会提交到Git仓库。

CI需要通过自己的配置系统注入：

• Secrets；

• Variables；

• Pipeline配置。

所以如果：

本地正常，CI失败

优先检查CI环境变量，而不是继续修改业务代码。

---

七、不要把敏感信息直接提交到仓库

如果Codex发现缺少：

API_KEY
TOKEN
PASSWORD

不要直接把真实值写进代码或者提交到Git。

更合适的做法通常是：

在：

.env.example

里保留变量名称：

API_KEY=

真实值继续通过本地环境或Secrets管理。

这样既能告诉项目“需要什么配置”，又不会暴露敏感信息。

---

八、可以直接验证程序实际读取到的配置

如果仍然无法判断，可以临时检查：

程序到底有没有加载到这个变量。

但对于密钥、Token等敏感配置，不要直接输出完整值。

可以只检查：

是否存在
长度是否正常
当前环境名称

例如确认：

DATABASE_URL 是否已经被加载？

而不是把完整数据库地址全部打印出来。

排查完成后，也要及时删除临时调试输出。

---

九、一个比较稳定的排查顺序

Codex修改环境变量后仍然报错，可以按这个顺序：

第一步：确认变量名称。

代码和配置必须完全一致。

第二步：确认实际加载哪个 .env。

避免其他配置覆盖。

第三步：重新启动服务。

让新配置真正加载。

第四步：检查当前Shell环境。

确认本地和Agent环境是否一致。

第五步：检查Docker或CI。

确认变量是否真正传入运行环境。

第六步：验证程序最终读取结果。

不要只盯着配置文件本身。

---

最后

Codex修改 .env 后项目还是报错，很多时候真正的问题并不是：

“变量没有写进去。”

而是：

写进了一个没有被当前环境读取的位置。

排查时可以重点确认：

读哪个文件、变量叫什么、服务有没有重启、运行环境到底在哪里。

尤其是涉及：

Docker、CI、测试环境和生产环境时，

不要默认本地 .env 会自动同步到其他地方。

只要把完整配置链路理清，很多环境变量问题通常都能快速定位。

---

持续更新 Codex、大模型开发与 AI 编程实战内容，更多技术内容和稳定订阅渠道欢迎搜索关注「仙逆GPT」。