JavaScript单例模式推荐用ES模块导出实例，因其天然单例、安全简洁；闭包封装次之；需用于共享状态、资源独占等场景，避免new调用和测试污染。
JavaScript 中单例模式的典型实现方式
单例模式的核心是「全局唯一实例 + 延迟初始化」，JS 没有原生 class 级访问控制，所以靠闭包或 Symbol + WeakMap 封装私有状态更可靠。最常用且安全的是模块级单例（利用 ES 模块天然单例特性）和函数内闭包封装。
推荐写法：
const Singleton = (function () {
let instance = null;
function createInstance() {
return {
data: [],
add(item) { this.data.push(item); },
getData() { return this.data; }
};
}
return {
getInstance() {
if (!instance) {
instance = createInstance();
}
return instance;
}
};
})();调用 Singleton.getInstance() 总返回同一对象。注意：不能用 new Singleton()，否则破坏单例语义。
ES 模块天然单例：最简洁、最安全的实践
现代 JS 项目中，直接导出一个对象实例比手写闭包更自然，也避免了多处引用时意外重建的风险。模块加载器保证整个应用生命周期只执行一次模块代码。
// logger.js
export const Logger = {
logs: [],
log(message) {
this.logs.push(`${new Date().toISOString()} - ${message}`);
},
getHistory() {
return [...this.logs];
}
};在任意文件中 import { Logger } from './logger.js'，所有导入都共享同一个 Logger 对象。这是目前生产环境首选方案，无需额外判断逻辑，无竞态风险。
需要防多实例的场景：哪些地方必须用单例？
不是所有“只用一个”的对象都需要刻意实现单例模式；关键看是否涉及**共享状态、资源独占、或跨模块一致性保障**。
-
WebSocket连接管理器：多个组件共用同一连接，避免重复握手和资源浪费 - 全局配置中心（如
ConfigService）：配置应统一加载、不可被局部覆盖 - 缓存容器（如
MemoryCache）：不同业务模块读写同一内存空间，需避免各自维护副本 - 日志上报器（含节流/批处理逻辑）：多个调用点必须聚合到同一个发送队列
反例：一个纯工具函数集合（如 StringUtils）不需要单例——它无状态，导出函数即可。
立即学习“Java免费学习笔记（深入）”；
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
容易踩的坑：new 实例、构造函数暴露、测试隔离失败
常见错误是把单例写成可 new 的类，导致使用者误用：
class BadSingleton {
constructor() {
this.id = Math.random(); // 每次 new 都不同！
}
}
// ❌ 错误用法
const a = new BadSingleton();
const b = new BadSingleton(); // a !== b正确做法是让构造函数私有化（JS 中只能靠约定或 WeakMap 拦截），或干脆不暴露构造函数。
另一个问题是单元测试时单例状态残留：上一个 test 修改了 Logger.logs，下一个 test 读到脏数据。解决方式是在每个 test 后重置（afterEach(() => { Logger.logs.length = 0; })）或使用依赖注入替代直接 import 单例模块。
真正难的不是写单例，而是判断「这个对象是否真的需要全局唯一性」——多数时候，模块导出 + 显式 import 已足够；只有当状态耦合深、生命周期复杂、或需跨 bundle 共享时，才值得引入显式单例封装逻辑。
