怎样用JavaScript创建单例？

单例模式是软件工程中一种常见且重要的设计模式，其核心目标是确保某个类在整个程序运行期间仅存在一个实例，并且提供一个全局访问点来获取该实例。在JavaScript这种基于原型和动态类型的语言中，由于模块系统和闭包等特性的存在，实现单例模式有着多种灵活的方式。合理运用单例模式可以有效管理全局状态、共享资源以及控制实例化成本，从而提升代码的健壮性与可维护性。

基于闭包与ES6 Class的单例构建策略

在早期的JavaScript开发中，闭包是实现单例模式最为经典且可靠的方式。闭包允许我们在函数内部创建私有变量，从而将实例的引用隐藏起来，防止外部代码直接修改或覆盖该实例。通过立即执行函数表达式或者返回一个带有静态方法的构造函数，我们可以严格控制实例的创建过程。当外部尝试获取实例时，系统会首先检查私有变量中是否已经存在实例，如果存在则直接返回，否则创建新实例并保存引用。这种方式虽然逻辑相对复杂，但提供了极高的数据安全性。

// 闭包实现单例
const Singleton = (function() {
    let instance = null;
    
    // 真正的构造函数
    function SingletonConstructor(name) {
        this.name = name;
        if (instance) {
            return instance;
        }
        instance = this;
    }
    
    // 获取实例的静态方法
    SingletonConstructor.getInstance = function(name) {
        if (!instance) {
            instance = new SingletonConstructor(name);
        }
        return instance;
    };
    
    return SingletonConstructor;
})();

// 测试单例效果
const s1 = Singleton.getInstance('实例1');
const s2 = Singleton.getInstance('实例2');
console.log(s1 === s2); // 输出 true，说明是同一个实例
console.log(s1.name); // 输出 实例1

随着ECMAScript标准的演进，ES6引入了class关键字，使得JavaScript的面向对象编程更加直观。利用class的静态属性和静态方法，我们可以非常优雅地实现单例模式。在构造函数内部，我们可以检查类本身的静态属性是否已经持有实例引用；同时，提供一个静态方法作为获取实例的统一入口。这种方式不仅代码结构清晰，而且更符合现代开发者的阅读习惯。但在安全性上，由于静态属性暴露在类对象上，理论上存在被外部恶意篡改的风险，因此在核心底层库中仍需谨慎使用。

class Singleton {
    constructor(name) {
        if (Singleton.instance) {
            return Singleton.instance;
        }
        this.name = name;
        Singleton.instance = this;
    }
    
    // 静态方法获取实例
    static getInstance(name) {
        if (!Singleton.instance) {
            Singleton.instance = new Singleton(name);
        }
        return Singleton.instance;
    }
}

// 测试单例效果
const s1 = Singleton.getInstance('实例A');
const s2 = new Singleton('实例B');
console.log(s1 === s2); // 输出 true
console.log(s1.name); // 输出 实例A

惰性单例模式的设计与性能优化

在实际的前端工程开发中，某些单例对象的创建成本可能非常高。例如，当我们需要在页面中渲染一个包含复杂交互逻辑的<div>弹窗容器，或者初始化一个重型的数据图表时，如果我们在应用启动时就立即初始化这些单例，可能会导致首屏加载时间变长，严重影响用户体验。为了解决这一问题，惰性单例模式应运而生。惰性单例的核心思想是延迟初始化，即只有在真正需要使用该实例的第一时间，才去执行创建逻辑，从而将性能开销分摊到用户交互的过程中。

为了实现通用的惰性单例逻辑，我们可以借助高阶函数来封装创建过程。通过编写一个接收创建函数的包装器，我们可以在内部维护一个闭包变量来缓存创建结果。当包装器返回的函数被调用时，它会检查缓存变量，若为空则执行传入的创建函数并保存结果，后续调用则直接返回缓存结果。这种设计将单例的管理逻辑与具体的业务创建逻辑彻底解耦，极大地提高了代码的复用性，使得任何高成本的创建函数都可以轻松转换为惰性单例。

const getSingleton = function(fn) {
    let instance = null;
    return function(...args) {
        if (!instance) {
            instance = fn.apply(this, args);
        }
        return instance;
    };
};

// 创建单例的具体业务函数
const createModal = function(text) {
    const div = document.createElement('div');
    div.innerHTML = text;
    document.body.appendChild(div);
    return div;
};

// 生成惰性单例的创建函数
const getSingletonModal = getSingleton(createModal);

// 首次调用时创建实例
const modal1 = getSingletonModal('弹窗内容');
// 后续调用返回同一个实例，不会重复创建DOM节点
const modal2 = getSingletonModal('另一个弹窗内容');
console.log(modal1 === modal2); // 输出 true

单例模式的工程化实践与注意事项

在选择具体的单例实现方式时，开发者需要根据项目的实际需求和团队的技术栈进行权衡。闭包实现提供了极佳的封装性和安全性，适合对数据隐私要求严格的底层库开发；ES6 Class实现语法简洁，适合常规的业务逻辑封装；而惰性单例则在处理高成本初始化任务时表现出众。为了更清晰地展示它们的差异，我们可以通过以下表格进行多维度的对比分析，帮助开发者在不同场景下做出最优选择。

在当下的模块化开发体系中，无论是CommonJS规范还是ES Modules规范，模块系统在底层都实现了缓存机制。这意味着当一个模块被多次导入时，模块内部的代码只会被执行一次，后续导入获取的都是同一个导出对象的引用。因此，在很多场景下，我们只需要在模块中导出一个普通的对象字面量，它天然就是一个单例，无需再手动编写复杂的单例控制逻辑。然而，必须警惕单例模式的滥用。过度使用单例会导致模块间产生隐式的强耦合，使得全局状态难以追踪和测试。在设计系统时，应优先考虑依赖注入等更利于解耦的设计方案，仅在确实需要全局唯一协调者时才引入单例模式。

// 模块化场景下的天然单例
// a.js
const singletonObj = {
    name: '模块单例',
    getData() {
        return this.name;
    }
};
export default singletonObj;

// b.js
import singleton from './a.js';
// 所有导入该模块的地方，拿到的都是同一个对象实例，无需额外封装

综上所述，单例模式在JavaScript中有着丰富的实现手段。从传统的闭包封装到现代的类语法，再到结合高阶函数的惰性加载，每一种方式都有其独特的应用价值。在实际工程中，我们不仅要掌握这些代码层面的实现技巧，更要深刻理解单例模式背后的设计哲学。合理控制全局状态、避免不必要的资源消耗、警惕模块间的隐式耦合，才是用好单例模式的关键所在。希望本文的梳理能够帮助你在未来的架构设计中，更加游刃有余地运用这一经典模式。

JavaScript单例模式闭包ES6_class修改时间：2026-06-03 00:30:43