使用 Codex 修改 Docker 项目时，经常会遇到一种很典型的问题：

本地文件明明已经改了，但容器里运行的还是旧代码。

常见表现包括：

• Codex已经修改源码，页面却没有变化；

• 重启容器以后仍然是旧版本；

• 本地文件和容器里的文件内容不一致；

• 重新执行 docker compose up 也没有生效；

• 只有重新 Build 镜像以后才恢复正常。

这种情况很多时候不是 Codex 没改成功，而是：

宿主机代码、Docker镜像和运行中的容器并不是同一层东西。

---

一、先确认Codex到底改了哪份代码

假设本地项目在：

/project/app

但机器上还存在：

/project/app-copy
/project/app-test

如果 Codex 修改的是 app-test，而 Docker Compose 挂载的是 /project/app，容器当然不会发生变化。

可以先确认当前项目目录：

pwd

再查看 Docker Compose 中实际挂载的路径。

第一步一定要确认：

Codex修改目录和Docker实际使用目录是不是同一个。

---

二、Volume挂载错误是最常见原因之一

开发环境经常配置：

volumes:
  - ./src:/app/src

这意味着宿主机：

./src

会覆盖容器里的：

/app/src

如果实际代码却在：

./frontend/src

那么Codex即使修改正确，容器也看不到。

所以遇到代码不生效时，重点检查：

• 宿主机挂载路径；

• 容器目标路径；

• 相对路径从哪里计算。

---

三、没有挂载源码时，代码可能已经被写进镜像

另一种项目可能没有直接挂载源码。

Dockerfile里使用：

COPY . /app

这种情况下，代码是在：

构建镜像时复制进去的。

Codex后来修改宿主机文件，不会自动改变已经存在的镜像。

这时候仅仅执行：

docker restart app

通常没有用。

因为重启的仍然是旧镜像。

需要重新构建，例如：

docker compose build
docker compose up -d

---

四、Build Cache为什么会让人误以为代码没更新？

Docker为了提高构建速度，会复用之前已经构建过的Layer。

例如：

COPY package.json .
RUN npm install
COPY . .

正常情况下，源码变化后最后的 COPY . . 应该重新执行。

但如果 Dockerfile、构建上下文或者 .dockerignore 配置有问题，就可能出现：

你以为新文件进入了镜像，实际上根本没有被复制。

可以尝试：

docker compose build --no-cache

但不要把 --no-cache 当成固定解决办法。

更重要的是确认：

为什么缓存没有按照预期失效。

---

五、检查.dockerignore

这个文件很容易被忽略。

例如：

src/generated
config
dist

如果 Codex 修改的文件正好被 .dockerignore 排除，那么 Build 时它不会进入镜像。

所以出现：

本地已经改了，重新Build还是旧代码。

可以检查：

.dockerignore

确认目标文件或目录有没有被忽略。

---

六、WORKDIR不一致也容易看错位置

Dockerfile可能写：

WORKDIR /app

但启动脚本实际进入：

/app/server

或者代码被复制到：

/usr/src/app

如果你进入容器后只检查 /app，可能会误以为文件没更新。

可以进入容器：

docker exec -it <container> sh

然后确认：

pwd

以及：

ls

找到应用真正运行的位置。

---

七、直接检查容器里的文件最有效

如果不确定问题出在哪，最直接的方法是：

对比宿主机和容器内部文件。

例如宿主机：

cat src/app.ts

然后进入容器：

docker exec -it <container> sh

再查看：

cat /app/src/app.ts

如果两边内容不同，问题基本就可以缩小到：

• Volume；

• 镜像；

• Build；

• 工作目录。

而不是继续修改业务代码。

---

八、什么时候只需要重启，什么时候必须重新Build？

可以简单区分。

使用Volume挂载源码

例如：

volumes:
  - ./src:/app/src

通常源码修改后不需要重新Build。

但应用进程如果没有热更新，可能需要：

重启服务或容器。

源码直接COPY进镜像

例如：

COPY . /app

源码发生变化以后通常需要：

重新Build镜像，再启动新容器。

所以不能把：

restart

和：

rebuild

当成同一个操作。

---

九、一个实用排查顺序

以后遇到 Codex 改完代码，但 Docker 仍然运行旧版本，可以按这个顺序：

第一步：确认Codex修改目录。

是不是当前项目？

第二步：检查Volume。

源码是否正确挂载？

第三步：检查**.dockerignore****。**

目标文件有没有被排除？

第四步：检查Dockerfile。

源码是挂载进去，还是Build时COPY进去？

第五步：进入容器查看真实文件。

确认容器里到底是哪一版代码。

第六步：决定重启还是重新Build。

不要盲目反复执行命令。

---

十、可以让Codex完成后主动检查Docker状态

以后可以在任务里增加：

修改完成后请确认：

1. 修改的是哪个本地目录；
2. Docker是否通过Volume挂载该目录；
3. 如果源码来自镜像，是否需要重新Build；
4. 检查.dockerignore；
5. 确认容器里的目标文件已经是最新版本；
6. 不要因为代码未生效就直接重复修改业务逻辑。

这样可以减少：

代码其实已经改对，只是容器没有加载新版本

这种重复返工。

---

最后

Codex在Docker项目里改完代码，容器却还是旧版本，真正需要排查的通常不是代码逻辑，而是：

宿主机 → Volume → Build Context → 镜像 → 容器运行目录

这一整条链路。

最关键的一步是：

直接进入容器确认它真正运行的是哪一份文件。

如果容器内还是旧代码，就先解决Docker同步问题。

不要急着让Codex再修改一次代码，否则很可能：

代码本来已经正确，却因为运行环境没更新，反而越改越复杂。

---

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