commonjs模块缓存是单例常驻设计，不可随意清理；直接删除require.cache会破坏依赖一致性、危及核心模块且无法解决状态泄漏；应通过工厂函数、状态外置和动态import等方案规避模块级状态。
CommonJS 的模块缓存不是“可随意清理的临时存储”，而是 Node.js 模块加载系统的核心设计：每个模块路径首次 require 时执行并缓存整个 Module 实例（含 module.exports 和闭包环境），后续 require 直接返回该缓存对象。这意味着缓存本质是“单例常驻”，不是传统意义的“可刷新缓存”。所以清理与复用的关键不在“删缓存”，而在“控制缓存的粒度和生命周期”。
为什么不能直接 delete require.cache[filename]？
看似可行，实则高危：
- 破坏模块依赖图：若 A → B、C → B，删掉 B 的缓存后，A 和 C 各自重新加载 B，可能产生两个不一致的 B 实例，引发状态错乱或内存重复占用
- 核心模块风险极大：误删
require.cache['fs']会导致后续所有文件操作失败 - 无法解决根本问题：即使清了缓存，只要模块里有模块级变量（如
const cache = new Map()），下次加载仍会新建一份——泄漏照旧
真正有效的“清理”思路：把状态从模块级移到可控作用域
老旧 BFF 或长期运行服务中，内存增长往往源于模块顶层声明的持久对象。正确做法是解耦模块定义与状态持有：
- 导出工厂函数而非实例：让调用方决定何时创建、如何传入依赖（如缓存实例、DB 客户端）
- 将
Map、连接池、定时器等交由上层容器管理（如 Express 中间件、请求上下文、DI 容器） - 避免在模块顶层写
let/const大对象；改用函数参数或闭包注入 - 示例改造前：
const dbClient = createPool()→ 改造后：module.exports = (dbClient) => { ... }
有限场景下可安全“复用”缓存的技巧
仅适用于开发调试、测试隔离等非生产环境：
- 按路径批量清理（谨慎）：
Object.keys(require.cache).filter(k => k.includes('src/utils')).forEach(k => delete require.cache[k]) - 配合
vm.Script或子进程实现完全隔离：每个测试用例跑在独立上下文，天然无共享缓存 - 利用
require.resolve()获取绝对路径，再精确删除（比相对路径更可靠） - 注意：以上操作后需
require同一模块才能触发重加载；仅删缓存不等于重执行
生产环境推荐的替代方案
与其对抗缓存机制，不如绕过它：
- 用 ES Module（.mjs 或 type="module"）+ 动态
import()：每次调用生成新执行上下文，天然无模块级状态残留 - 对配置类模块，改用纯函数 + 参数传入：避免依赖模块缓存来“记住”配置
- 监控
require.cache大小和 key 数量，及时发现异常膨胀（比如意外require了大量临时文件） - 升级 Node.js 版本，利用现代诊断工具（
node --inspect+ Chrome DevTools）定位真实内存泄漏点
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
