JavaScript单例模式核心是确保类唯一实例并提供全局访问点，主要实现方式有闭包+IIFE（兼容性好）、ES6 class+静态属性（语义清晰）、模块模式（天然单例、最自然）及带参懒加载变体，选择取决于项目兼容性、规范与团队习惯。
JavaScript中实现单例模式的核心是：确保一个类只有一个实例，并提供全局访问点。由于JS没有类的私有成员和构造器控制机制，实现方式更灵活但也需注意闭包、模块作用域和ES6+语法特性。
使用闭包 + IIFE（最经典、兼容性最好）
利用立即执行函数返回一个对象，内部变量被闭包保护，外部无法重复创建实例。
- 第一次调用时创建实例，后续直接返回缓存对象
- 适合老项目或需要支持IE等旧环境的场景
const Singleton = (function() {
let instance = null;
function createInstance() {
return { data: 'I am the only instance' };
}
return {
getInstance: function() {
if (!instance) {
instance = createInstance();
}
return instance;
}
};
})();
// 使用
const a = Singleton.getInstance();
const b = Singleton.getInstance();
console.log(a === b); // true
使用ES6 class + 静态属性（简洁清晰，推荐现代项目）
借助class语法和静态属性保存实例，构造函数限制多次初始化（可选throw错误）。
- 构造函数内检查是否已存在实例，存在则抛错或忽略
- getInstance方法统一入口，语义明确
- 注意：new Singleton() 不再是标准用法，应只调用 Singleton.getInstance()
class Singleton {
constructor() {
if (Singleton.instance) {
throw new Error('Use Singleton.getInstance() instead');
}
this.data = 'Singleton instance';
Singleton.instance = this;
}
static getInstance() {
if (!Singleton.instance) {
Singleton.instance = new Singleton();
}
return Singleton.instance;
}
}
使用模块模式（天然单例，最自然的JS方案）
ES6模块本身具有“单例”语义：一个模块文件无论被import多少次，都只执行一次，导出对象始终是同一个引用。
立即学习“Java免费学习笔记（深入）”；
- 无需手动管理实例，无竞态风险，零配置
- 适合配置对象、工具实例、状态管理器等场景
- 本质是语言级单例，不是“模拟”，而是直接利用模块机制
// singleton.js
export const instance = {
data: 'Module-based singleton',
count: 0,
increment() { this.count++; }
};
// app.js
import { instance as a } from './singleton.js';
import { instance as b } from './singleton.js';
console.log(a === b); // true
带参数的懒加载单例（进阶：支持初始化配置）
当单例需要首次创建时传入配置，又不希望每次调用都重新初始化，可用惰性工厂函数封装。
- getInstance接受参数，但仅首次生效；后续调用忽略参数
- 用WeakMap或闭包变量保存配置与实例映射（如需多配置变体）
- 简单场景下，直接在闭包中缓存参数即可
const ConfigurableSingleton = (function() {
let instance = null;
let config = null;
return {
getInstance: function(options = {}) {
if (!instance) {
config = { ...options, createdAt: Date.now() };
instance = { config, doSomething() { return 'done'; } };
}
return instance;
}
};
})();
基本上就这些。模块模式最轻量可靠，闭包IIFE最通用，class写法最贴近传统OOP理解。选择哪种取决于项目规范、兼容要求和团队习惯——单例本身不复杂，但容易忽略初始化时机和测试隔离问题。
