commonjs模块缓存无自动过期机制，需手动删除require.cache中的绝对路径项（通过require.resolve获取）以触发重新加载；该操作仅重执行顶层代码，不销毁原对象，且仅适用于开发测试，生产环境应避免。
CommonJS 模块缓存本身没有“过期时间”机制，它是一次加载、永久驻留的静态缓存。所谓“手动过期更新”，本质是**主动删除缓存项，触发下次 require 时重新加载模块**，而非等待自动失效。
必须用 require.resolve() 获取绝对路径
require.cache 的键是模块的绝对路径（如 /project/src/utils.js），不是相对路径（./utils）或裸名（utils）。直接写字符串容易出错，尤其在跨平台或不同工作目录下。
- 调用 require.resolve('./my-module.js') 获取真实路径，它会按 Node 解析规则（.js → .json → .node）找到实际文件，并返回带扩展名的绝对路径
- Windows 路径中的反斜杠会被 normalize 成正斜杠，与 cache 中一致，无需手动替换
- 避免硬编码路径——路径变化时代码立即失效
删除缓存项后 require 才会重新执行
delete require.cache[modulePath] 只是移除引用，不销毁模块对象；但后续 require() 会像首次加载一样，重新执行模块顶层代码、生成新 Module 实例并写入 cache。
- 模块内定义的函数、类不受影响，但顶层变量（如 const data = {}）会被重置
- 如果模块导出的是对象字面量或 class 实例，新 require 返回的是全新对象，与旧实例无关联
- 注意副作用：若模块含 require('fs').writeFileSync() 或启动定时器，重复加载可能引发冲突
仅限开发/测试场景，严禁用于生产
在 BFF 或长期运行的服务中，随意清理 require.cache 会破坏模块依赖一致性。例如误删 fs 模块缓存，可能导致后续所有 require('fs') 失败。
- 常见安全用途：单元测试中隔离模块状态、热重载脚本、CLI 工具中动态加载配置
- 生产环境应通过架构设计规避缓存依赖——比如用工厂函数替代单例模块，把状态交由请求上下文管理
- 不要遍历或清空整个 require.cache，风险极高
ESM 不兼容，需确认模块系统
require.cache 是 CommonJS 特有机制，ESM（import/export）模块不走这套缓存逻辑，也无法用 delete require.cache 控制。
- 混合项目中，若目标文件已被 ESM 加载（如通过 import），require() 再加载会走 CommonJS 分支，但两者缓存独立
- 检查文件是否被 .mjs 后缀或 package.json 中 "type": "module" 影响，避免预期外的行为
- Node v14+ 支持 --experimental-loader，但 require.cache 仍只对 CommonJS 生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
