使用 Codex 修改前端项目时，经常会遇到一种很容易误判的问题：
代码明明已经保存了，浏览器里的页面却还是旧效果。
常见表现包括：
- Codex已经修改了文件，但页面没有任何变化；
- 手动刷新浏览器也不生效；
- 重启开发服务器以后突然正常；
- 有些文件修改后能立即更新，有些文件却完全没反应；
- 本地直接运行正常，Docker、WSL环境下热更新经常失效；
- 看起来像Codex没改对，实际重复修改几次以后还是一样。
这类问题很多时候并不是代码写错了，而是：
文件虽然变了，但开发服务器没有感知到这次变化。
所以页面不更新时，不要第一时间继续让 Codex 改业务代码。
一、先确认改的是不是"正在运行的那份文件"
这是最容易忽略的一步。
一个项目里可能同时存在：
src源码；dist或build编译产物；- 多个相似组件；
- Monorepo中的多个Package；
- Docker容器内部另一份代码。
Codex修改了：
src/pages/User.tsx
但当前页面实际引用的可能是另一个：
packages/admin/User.tsx
这时候文件确实改了，页面当然不会变化。
所以先确认：
当前页面实际加载的是哪一个文件。
二、保存成功，不代表Watcher收到了变化
Vite、Webpack、Next.js等开发服务器通常依赖文件监听机制。
正常流程应该是：
文件变化 → Watcher检测 → 重新编译 → HMR更新页面
如果第二步没有发生，后面全部不会执行。
修改文件后，可以观察开发服务器终端。
正常情况下通常会看到重新编译、模块更新之类的信息。
如果终端完全没有反应，就应该优先怀疑：
文件监听没有收到变更事件。
三、Docker和WSL特别容易出现监听问题
在Docker开发环境里，经常会通过Volume把宿主机代码挂载进容器。
例如：
宿主机修改文件
↓
Volume同步到容器
↓
容器里的Watcher检测变化
这里任何一步出问题，页面都可能不更新。
尤其是在Windows、WSL、Docker Desktop组合环境中，文件系统事件有时不能稳定传递。
于是出现：
文件确实已经变了，但开发服务器不知道。
这时候可以检查是否需要使用轮询模式，例如让Watcher定期检查文件变化，而不是完全依赖系统事件。
四、HMR失效和开发服务器没重载不是一回事
热更新失败通常有两种情况。
第一种：
开发服务器已经检测到文件变化，但浏览器没有正确替换模块。
这属于HMR问题。
第二种：
开发服务器从头到尾都不知道文件变了。
这属于文件监听问题。
两者的排查方向不同。
最简单的判断方法是看终端：
如果保存文件后出现重新编译日志，但页面不变，可以继续检查HMR。
如果连编译日志都没有，就应该先检查Watcher。
五、缓存也可能让你一直看到旧结果
有时候开发服务器已经重新构建，但浏览器仍然显示旧资源。
可以检查：
- 浏览器缓存；
- Service Worker；
- Vite缓存；
- Next.js缓存目录；
- 构建产物缓存。
例如项目经过一次异常构建后，旧缓存没有正确失效，就可能让页面一直使用之前的结果。
这时候可以尝试：
强制刷新 → 清理开发缓存 → 再重新启动服务。
但不要一上来就删除所有目录。
先确认问题到底是不是缓存。
六、为什么重启开发服务器后就正常？
这是一个非常重要的信号。
如果：
保存文件不生效
但：
重启开发服务器立即正常
通常说明代码本身大概率已经修改正确。
问题更可能出在：
- Watcher；
- HMR；
- 缓存；
- Volume同步；
- 开发服务器状态。
因为重新启动时，服务器会重新扫描整个项目，之前漏掉的文件变化也会重新读取。
所以这种情况下继续让Codex重写组件，意义通常不大。
七、可以用一个简单办法确认文件到底有没有被重新读取
修改一个非常明显的内容，例如页面上一段测试文字。
保存以后观察：
- 文件时间戳是否变化；
- 开发服务器是否输出重新编译日志；
- Network里相关资源是否重新加载；
- 浏览器页面是否更新。
这样可以快速确定问题停在哪一层。
排查链路其实就是：
文件修改 → Watcher → 编译 → HMR → 浏览器
不要直接从最后一层反推整个代码都有问题。
八、还有一种情况：运行的是旧进程
本地同时启动多个开发服务器时也很容易出问题。
例如：
一个终端运行3000端口；
另一个旧进程运行5173端口；
你修改的是新项目，却一直打开旧服务页面。
或者代理仍然指向旧端口。
这时候不管Codex改多少代码，页面都不会变化。
所以还要确认：
当前浏览器访问的端口，和你正在修改、正在运行的项目是不是同一个。
九、一个实用的排查顺序
遇到Codex改完代码、保存后页面不生效，可以按照这个顺序：
第一步：确认真实修改文件。
页面到底引用的是哪一份代码。
第二步：看开发服务器日志。
保存后有没有重新编译。
第三步：检查Watcher。
Docker、WSL、网络盘环境是否丢失文件事件。
第四步：检查HMR。
服务器已编译，但浏览器是否没有正确更新。
第五步：检查缓存。
浏览器、Service Worker、框架缓存是否仍在使用旧内容。
第六步：确认运行进程和端口。
避免一直访问旧服务。
十、可以直接这样让Codex排查
遇到这类问题时，可以直接要求：
请不要继续修改业务代码，先确认当前页面实际加载哪个源文件。检查文件保存后开发服务器是否检测到变化，并区分Watcher失效和HMR失效。若项目运行在Docker或WSL中，检查Volume和文件监听；同时确认浏览器缓存、Service Worker、开发缓存以及当前访问端口。最后指出文件变化具体在哪一层没有继续传递。
这样比反复让Codex：
再改一下这个组件。
有效得多。
最后
Codex改完代码后页面一直不生效，真正的问题不一定是：
代码没有改对。
更可能是：
代码虽然已经改变，但变化没有完整传递到浏览器。
最稳的排查思路就是沿着：
源文件 → 文件监听 → 开发服务器 → HMR → 浏览器
逐层确认。
尤其是"重启以后马上正常"这种情况，更应该优先检查开发环境，而不是继续扩大代码修改范围。
持续更新 Codex、大模型开发与 AI 编程实战内容，更多技术内容和稳定订阅渠道欢迎搜索关注「仙逆GPT」。