单例与缓存机制在JS模块加载中的应用

JavaScript模块系统（无论是CommonJS还是ES Modules）天然具备单例特性——同一模块路径仅被加载和执行一次，其导出对象被所有导入者共享引用，这一行为并非开发者手动实现的设计模式，而是由Node.js的require.cache或ESM的Module Record等加载器底层缓存机制强制保障的规范契约；它让全局配置、数据库连接、状态管理器等需要唯一性的资源得以安全、轻量、无感地复用，同时也提醒开发者注意顶层副作用的不可重复性及测试时的缓存残留问题。

JavaScript模块系统（如ES6 Modules、CommonJS）天然支持单例行为——同一模块路径在应用中只会被加载和执行一次，后续导入都复用首次执行后的导出对象。这背后不是开发者手动实现的单例模式，而是模块加载器（如Node.js的模块缓存、浏览器ESM的模块记录表）强制保证的缓存机制。

模块缓存由加载器自动管理

以Node.js为例，require() 会将已加载模块的 exports 对象 缓存在 require.cache 中。再次 require 同一路径时，直接返回缓存中的 exports，不再执行模块代码。这意味着：

• 模块顶层代码（如初始化逻辑、变量声明）只运行一次
• 导出的对象（函数、类、对象字面量等）是共享引用，修改其属性会影响所有导入者
• 即使模块路径写法不同（如 ./util 和 ./util.js），只要解析后指向同一文件，就命中同一缓存项

ES模块（ESM）同样遵循单例语义

浏览器和Node.js对 import 的处理也确保模块实例唯一：

• 每个模块规范地址（specifier）对应一个 Module Record，整个生命周期内仅实例化一次
• 导入绑定（import { x } from './m.js'）是实时绑定（live binding），指向模块内部的同一内存位置
• 即便多个文件 import 同一模块，它们共享的是同一个导出值，而非副本

这不是“设计模式”，而是规范契约

注意：这不是开发者用 class Singleton 或闭包模拟的单例模式，而是一种由模块系统保障的底层行为。它不可关闭、不可绕过（除非动态构造不同路径或使用 import() 动态导入并配合不同参数欺骗解析器）。因此：

• 适合存放全局配置、连接实例（如数据库client）、状态管理器等需要唯一性的对象
• 要避免在模块顶层做副作用操作（如修改全局变量），除非你明确依赖它的“只执行一次”特性
• 测试时需注意：模块缓存会跨测试用例保留，必要时可通过 delete require.cache[moduleName]（Node.js）手动清理

与手写单例的关键区别

传统单例模式（如私有构造+静态 getInstance）控制的是类的实例数量；而模块单例控制的是模块执行和导出对象的唯一性。两者目标相似，但层级不同：

• 模块单例作用于整个模块作用域，无需额外封装
• 手写单例仍可能被 new 多次（除非严格限制构造器），模块单例则从机制上杜绝重复初始化
• 模块单例更轻量、更自然，是现代JS工程的默认实践基础

今天关于《单例与缓存机制在JS模块加载中的应用》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！