create-react-app编译报错后源文件疑似缓存导致错误提示不消失

该问题的核心触发逻辑并非传统浏览器缓存，而是CRA在Windows环境下的dev服务监听机制、本地编译缓存的缺陷导致的，具体可按以下步骤逐层排查解决：

清理所有顽固编译缓存 #

• 终止所有运行中的Node进程：关闭所有运行npm服务的终端，打开任务管理器结束全部node.exe进程，避免缓存文件被进程占用无法删除
• 删除项目内置的编译缓存目录：直接删除项目路径下的node_modules/.cache文件夹，该目录存储了webpack、babel-loader、eslint的全部持久化编译结果。很多时候重启服务不生效，就是因为该目录下的旧编译结果没有被清除
• 完成上述操作后重新执行npm run start即可加载全新的编译上下文，不需要重命名文件、调整全量文件引用。

修复Windows下文件监听失效问题 #

该问题“触发概率高但不每次出现”、甚至把仓库拉取到全新目录重装依赖也会复现的特性，本质是Windows系统原生的文件事件监听机制存在缺陷：CRA默认使用的chokidar、watchpack组件在遇到编辑器保存时的临时文件锁、自动保存延迟写入时，会直接丢失后续的文件变更事件——哪怕磁盘上的源文件已经完成修改，dev服务根本感知不到文件变化，自然会一直展示第一次编译时捕获的旧错误。

• 在项目根目录（和package.json同级）新建.env配置文件，加入两行监听配置：
  • CHOKIDAR_USEPOLLING=true：开启轮询式文件监听，绕开Windows原生文件监听的事件丢失问题
  • WATCHPACK_POLLING=true：覆盖webpack内置watchpack模块的监听逻辑，和chokidar配置互补，避免webpack层的监听失效
• 该配置开启后的性能损耗极低，即便项目包含上千个源文件，轮询的资源占用也远低于反复重命名文件、调整全量引用的开发成本。

规避缓存锁导致的旧结果残留 #

• 如果使用的是5.x版本以上的react-scripts，默认开启了babel-loader的持久化缓存，遇到文件锁场景时会直接把旧的编译结果固化在缓存目录中，哪怕源文件已经更新也会优先读取旧缓存。可在.env文件中加入BABEL_CACHE=none关闭该持久化缓存，减少缓存锁触发概率
• 如果项目使用TypeScript，可在.env中加入TSC_COMPILE_ON_ERROR=true，避免类型检查进程在第一次遇到编译错误后就停止监听后续文件变更，一直返回初始的错误信息。

临时应急操作 #

遇到dev服务卡住、错误提示不刷新时，不需要关闭终端重开，直接在运行dev服务的终端窗口连续输入两次rs后按回车，即可手动重启webpack-dev-server的监听实例，快速恢复文件变更监听能力。

内容的提问来源于stack exchange，提问作者Philipp