Node 编译缓存卡住

Windows 上调用 module.enableCompileCache() 后没有返回，进程持续占用 CPU，业务入口也没有继续执行。若缓存目录较深或接近某些路径限制，先检查同步创建缓存目录的路径，而不是把它当作编译还没完成。

这个症状出现在 Node 24.18.0，后续环境也包含 24.21.0 和 26.10.0。已核对的正式版 26.11.1 为对应的目录创建重试增加了边界。不能只凭开发分支已修或 nightly 能返回，就认为旧正式部署已经包含修复。

缓存目录还会附加子目录

Node 不只使用调用方给出的路径，还会在其中创建带版本等标记的缓存子目录。因此，父目录存在、路径看起来可写，并不足以证明最终目录能够创建。

旧同步 MKDirpSync 遇到 ENOENT 时，会把当前目录和父目录重新放进待处理路径。正常情况下，先创建父目录再重试是合理的；但特定 Windows 路径布局仍无法创建目标时，同一个失败路径可能被反复处理，调用始终不结束。

这里不能给出一个适用于所有机器的“超过 240 或 260 个字符就必现”阈值。目录分段、附加标记和系统行为都会影响最终路径。应保留实际缓存目录、Node 版本、Windows 条件和调用位置，按具体布局核对。

如果进程正在编译业务代码、读取网络资源或运行启动钩子，应先根据已有日志和调用位置排除它们。单凭 CPU 高，不能归到缓存目录重试。

优先让优化失败能够返回

26.11.1 的正式目录创建逻辑记住已经因 ENOENT 重试过的路径；同一路径再次失败时返回错误，而不是继续循环。缓存启用路径随后能按结果给出失败状态。

项目应选择包含相应处理、且符合运行时兼容要求的正式版本。本文只核定这一正式实现，不指定其他发行线最早包含修复的补丁。

enableCompileCache() 是优化入口，正常 API 通过结果中的 status 和 message 表达无法启用等情况。业务启动应按这些状态处理，不能只为使用缓存而无限等待。捕获 JavaScript 异常也无法让已经卡在同步目录创建里的旧调用恢复。

需要先恢复启动时

可以在自己拥有的该 Node 实例启动配置中设置 NODE_DISABLE_COMPILE_CACHE=1，暂时关闭编译缓存。它不是关闭模块加载；业务仍按正常方式运行，只是失去这项优化。保留原配置，后续在兼容升级与验收后恢复。

另一种有条件的处理是使用明确、较短且可写的缓存目录，并核对最终附加子目录。不要删除整个临时目录、改动用户数据或全局调整 Windows 长路径策略来尝试消除这个循环。

若应用自己显式调用启用接口，也应确认禁用配置被当前 Node 实例读取，而不是只改了另一个终端或服务。worker、容器和不同启动包装器可能使用另一份环境，需要按真实入口核对。

验收返回状态与业务启动

在受控环境中使用原先失败的路径条件，确认启用调用能够有界返回，状态和错误信息符合实际目录情况。若目标目录仍无效，返回失败是正确结果，不应要求它必须显示启用成功。

随后检查业务入口正常运行，进程不再持续旋转。只看某次 CPU 降下来不够，也不能在恢复启动后假定编译缓存已经启用；是否启用应继续由 API 状态和实际配置确认。