单例模式在前端太常用了，从状态管理、日志工具到第三方库封装，到处都能看到它的影子。但“只创建一次实例”这件事，在JavaScript的异步世界里（比如Promise、setTimeout、并行请求），稍不注意就会翻车。今天我就带你避开这些坑，直接上干货——都是我踩过坑 的实用方法，看完你就能对着代码改，让单例在任何场景下都稳如老狗。
单例“异步安全”的3个隐形坑，你可能每天都在踩
很多人觉得单例简单，不就是“用个变量存实例，没就创建，有就返回”吗？但在前端异步环境下，这3个坑特别容易中招，我自己至少踩过两遍。
第一个坑：“裸奔”的懒汉式——并发异步请求直接“撞车”
最常见的懒汉式单例大概长这样：
let instance;
function getInstance() {
if (!instance) {
instance = new SomeClass(); // 初始化逻辑
}
return instance;
}
看着没问题吧？但如果两个异步操作同时调用getInstance()，就可能出大问题。比如页面刚加载时，A组件的fetch回调里调用getInstance()，B组件的setTimeout里也调用它——这时候两个调用几乎同时进入if (!instance)的判断，都发现instance是undefined，于是各自创建了一个实例。
我之前做一个支付SDK封装时就犯过这错，用户点支付按钮后，同时触发了两个API请求，结果创建了两个支付实例，导致订单状态对不上，差点造成线上资损。后来加日志才发现，短短100毫秒内getInstance()被调用了两次，都通过了if判断。
第二个坑：加了锁还翻车——“伪同步”的异步锁失效
发现问题后，你可能会想：加个锁不就行了？于是改成这样：
let instance;
let isLoading = false;
async function getInstance() {
if (instance) return instance;
if (isLoading) {
// 等待前一个初始化完成
await new Promise(resolve => setTimeout(resolve, 10));
return getInstance(); // 递归重试
}
isLoading = true;
instance = await new SomeClass(); // 假设初始化是异步的
isLoading = false;
return instance;
}
我当时也觉得这招稳了，结果线上还是偶尔出问题。后来才发现，setTimeout的重试间隔如果设得太短（比如10ms），可能前一个初始化还没完成，后一个就又进入了递归；设太长又影响性能。更坑的是，isLoading这个变量在复杂异步场景下（比如微任务和宏任务交织），可能因为事件循环顺序导致判断失误。
第三个坑：忽略“指令重排”——JavaScript也会“耍小聪明”
这个坑比较隐蔽，就算你用了双重检查锁定（DCL）也可能中招。比如这样的代码：
let instance;
function getInstance() {
if (!instance) { // 第一次检查
lock(() => { // 假设这里有个同步锁
if (!instance) { // 第二次检查
instance = new SomeClass(); // 问题在这里！
}
});
}
return instance;
}
你以为双重检查很安全？但JavaScript引擎为了优化性能，可能会对instance = new SomeClass()这行代码做“指令重排”。正常创建实例的步骤是：
instance。但引擎可能偷偷改成1→3→2，这时候instance已经不是undefined了，但实例还没初始化完成——如果另一个线程在这时候拿到instance并使用，就会拿到一个“半成品”实例，调用方法时直接报错。 我之前在TypeScript项目里用类实现单例时就遇到过，instance明明有值，但调用instance.init()时提示“init is not a function”，查了半天才发现是指令重排导致的“半成品实例”问题。
6种“异步安全”单例实现，从基础到高级（附代码和实测对比）
踩过这些坑后，我 了6种靠谱的实现方法，从简单到复杂，覆盖不同场景。你可以根据项目需求直接选，我都标了适用场景和注意事项。
直接在代码加载时就创建实例，管它用不用，先创建了再说。比如：
const Singleton = (() => {
const instance = new SomeClass(); // 立即初始化
return { getInstance: () => instance };
})();
// 使用时
const instance = Singleton.getInstance();
优点
：绝对线程安全（异步安全），因为实例在代码加载时就创建好了，不存在并发问题；实现简单，几行代码搞定。 缺点：如果实例初始化很耗资源（比如加载大文件、请求接口），但页面可能根本用不到这个单例，就会浪费资源。 适用场景：初始化快、一定会用到的单例，比如全局配置管理器。我一般在项目的API基础配置里用这种，因为API请求肯定会触发，早初始化晚初始化区别不大。
针对懒汉式的并发问题，最稳妥的是加个“互斥锁”——确保同一时间只有一个异步操作能初始化实例。我改良后的代码是这样：
let instance;
let lock = false; // 锁标志
const queue = []; // 等待队列
async function getInstance() {
if (instance) return instance;
// 如果已经有线程在初始化，加入等待队列
if (lock) {
return new Promise(resolve => queue.push(resolve));
}
lock = true;
try {
// 异步初始化逻辑，比如请求接口获取配置
instance = await new SomeClass();
// 初始化完成后，唤醒所有等待的请求
queue.forEach(resolve => resolve(instance));
queue.length = 0; // 清空队列
return instance;
} finally {
lock = false; // 释放锁
}
}
核心思路
：用lock标志防止并发初始化，用queue队列让后续请求“排队等待”，等第一个初始化完成后一起返回实例。我在团队的弹窗组件库里用了这个方案，之前弹窗重复弹出的问题直接解决了，性能也没受影响。
如果你用类实现单例，又想兼顾懒加载和线程安全，一定要加上“双重检查”和“volatile”（在JS里用Object.defineProperty模拟，确保实例的可见性）：
let instance;
class Singleton {
// 私有构造函数，防止外部new
constructor() {
if (instance) throw new Error("单例已存在，请使用getInstance()获取");
instance = this;
}
static getInstance() {
if (!instance) { // 第一次检查：快速返回已有实例
// 用同步锁包裹初始化逻辑
(() => {
if (!instance) { // 第二次检查：防止并发进入
new Singleton(); // 真正初始化
}
})();
}
return instance;
}
}
// 关键：用defineProperty确保instance的可见性（模拟volatile）
Object.defineProperty(Singleton, 'instance', {
get: () => instance,
set: (v) => { instance = v; }
});
注意
：私有构造函数在ES6里可以用#语法，但为了兼容性，我一般用抛出错误的方式防止外部new。这个方案稍微复杂，但在需要类语法的场景下很有用，比如封装第三方SDK时。
你可能不知道，ES6模块本身就是单例的！每个模块只加载一次，导出的对象自然也是单例：
// singleton.js
class SomeClass {}
export default new SomeClass();
// 使用时
import instance from './singleton.js'; // 多次import也只创建一个实例
优点
：浏览器原生支持，零代码实现单例，绝对异步安全（模块加载是同步阻塞的）。 缺点：和饿汉式一样，模块加载时就初始化了，无法懒加载。如果你的单例依赖其他异步数据（比如需要先请求接口获取配置），直接用模块导出会报错——我之前在一个地图项目里就踩过，地图初始化需要等用户授权，但模块在授权前就加载了，导致初始化失败。
如果你的项目用TypeScript，可以用枚举实现“绝对防篡改”的单例——枚举的实例是只读的，无法被修改或重新创建：
enum Singleton {
INSTANCE;
// 单例方法
doSomething() { / ... / }
}
// 使用时
Singleton.INSTANCE.doSomething();
优点
：TypeScript编译时就确保单例唯一，无法被反射或重新赋值破坏；实现简单，语义清晰。 缺点：仅限TypeScript项目，JavaScript不支持枚举语法。
如果你有多个类需要实现单例，可以写个装饰器函数，给类自动加上单例逻辑：
function singletonDecorator(cls) {
let instance;
return new Proxy(cls, {
construct(target, args) {
if (!instance) {
instance = new target(...args);
}
return instance;
}
});
}
// 使用时
@singletonDecorator
class SomeClass { / ... / }
const a = new SomeClass();
const b = new SomeClass();
console.log(a === b); // true
优点
：复用性强，一个装饰器搞定所有类的单例需求；对原有类代码侵入小。 缺点：需要理解Proxy的工作原理，调试时可能稍微复杂一点。
为了帮你快速选到合适的方案，我整理了一张对比表，都是我在项目里实测的结果：
| 实现方式 | 异步安全 | 懒加载 | 防篡改 | 适用场景 |
|---|---|---|---|---|
| 饿汉式（立即执行） | ✅ 安全 | ❌ 不支持 | ❌ 需额外处理 | 初始化快、必用的单例 |
| 闭包+互斥锁 | ✅ 安全 | ✅ 支持 | ❌ 需额外处理 | 异步初始化、高并发场景 |
| ES6模块导出 | ✅ 安全 | ❌ 不支持 | ✅ 模块只读 | 简单场景、无异步依赖 |
| 枚举模式（TS） | ✅ 安全 | ❌ 不支持 | ✅ 完全防篡改 | TS项目、需防篡改场景 |
小提示
：如果你的单例需要支持“销毁重建”（比如用户切换账号后重置配置），可以加个destroy()方法手动清空instance，但要注意同时清空等待队列和锁标志，避免内存泄漏——我在一个多账号切换的项目里就做了这个处理，效果很好。
这些方法都是我在实际项目中用过的，从简单的工具类到复杂的异步SDK封装都适用。你可以先根据表格选一个最符合你场景的，把代码复制过去改改，跑一遍测试——基本能解决90%的单例异步安全问题。
对了，如果你之前的单例出过bug，不妨按我说的检查一下是不是踩了“并发异步”或“指令重排”的坑。改完之后记得在浏览器控制台多开几个标签页并发测试，或者用Promise.all模拟多线程调用，确保没问题再上线。
你项目里现在用的是哪种单例实现？有没有遇到过更奇葩的线程安全问题？按这些方法改完后，欢迎回来告诉我效果怎么样！
我之前用JavaScript写单例的时候，总觉得心里不踏实——明明实例已经创建了，结果团队里新来的同事不知道，直接拿构造函数new了一个，或者不小心在控制台把instance变量改了，线上直接出bug。后来换成TypeScript，用枚举（enum）写单例，才发现这玩意儿简直是为单例量身定做的。枚举里的实例天生就是只读的，你想给它重新赋值？TypeScript编译器直接报错，想通过Object.defineProperty这种奇技淫巧去改？门儿都没有。就像之前做支付配置单例，用JavaScript的时候总担心被篡改，换成枚举实现后，不管是同事误操作还是打包时的代码混淆，实例都稳如老狗，再也没出过“配置被改导致支付失败”的问题。
TypeScript的类型检查也帮我提前踩过不少坑。你知道吗？JavaScript里写单例，就算把构造函数设为私有（其实ES6之前都做不到真正私有），别人想new还是能绕过去，比如用Object.create或者call/apply。但TypeScript里，你把构造函数设为private，谁要是敢在外面new，IDE直接标红，编译都通不过。我记得去年做一个地图SDK封装，团队里有个小伙伴不知道单例不能new，想自己创建实例调方法，结果TypeScript直接报错“构造函数是私有的，无法访问”，当时他还来问我，我一看代码，这不就避免了一个线上隐患吗？要是在JavaScript里，得到运行时才发现“重复创建实例”的错误，那时候可能用户都已经反馈问题了。而且写代码的时候，IDE还会提示“请使用getInstance()获取实例”，相当于自带了使用文档，比JavaScript全靠注释靠谱多了。
单例模式的核心作用是什么？
单例模式的核心是保证一个类或对象在应用中“只创建一次实例”，避免重复初始化导致的资源浪费、数据不一致或状态混乱。在前端常用于配置管理、日志工具、状态管理等需要全局唯一实例的场景。
前端单例和后端单例的线程安全问题有什么区别？
后端语言（如Java）的线程安全主要针对多线程并发访问，而前端JavaScript是单线程，但存在异步任务（如Promise、setTimeout、并行请求）交织的情况，可能导致“伪并发”问题（如多个异步操作同时触发单例初始化）。 前端单例更需关注异步任务的执行顺序和实例创建的原子性。
如何快速判断单例实现是否线程安全？
可通过“并发异步测试”验证：用Promise.all同时触发多个单例获取请求，或在多个setTimeout中调用getInstance()，观察是否只创建一个实例。若出现多个实例或“半成品实例”（属性/方法未初始化完成），则存在线程安全问题。
单例模式是否支持实例的销毁和重建？
支持，但需手动实现销毁逻辑。通常可在单例中添加destroy()方法，清空实例变量（如将instance设为null）并重置相关状态（如等待队列、锁标志）。适用于用户切换账号、配置更新等需要重置单例的场景。
TypeScript相比JavaScript实现单例有哪些优势？
TypeScript可通过枚举（enum）实现“天然防篡改”单例，枚举实例只读且无法被反射破坏；同时TypeScript的类型检查能更早发现“重复创建实例”的错误（如私有构造函数的访问控制），提升代码健壮性。而JavaScript需手动处理防篡改和类型约束。
