发布于 由admin

JavaScript 中的单例模式：利用闭包、IIFE 或 ES Modules 实现线程安全的单例

JavaScript 中的单例模式：利用闭包、IIFE 或 ES Modules 实现线程安全的单例

在软件工程中，单例模式是一种创建型设计模式，它确保一个类只有一个实例，并提供一个全局访问点来获取这个实例。这种模式在需要严格控制资源访问、维护全局状态或确保特定组件只存在一份时非常有用，例如配置管理器、日志记录器、数据库连接池或事件总线。

在 JavaScript 这个单线程的运行时环境中，"线程安全" 的概念与传统多线程语言（如 Java、C#）有所不同。JavaScript 的主线程本身是单线程的，这意味着代码是顺序执行的，不会出现传统意义上的多个线程同时修改一个变量的竞态条件。然而，"线程安全" 在 JavaScript 中更多地指的是：

  1. 防止异步操作导致的多次实例化： 在异步编程模式下（如 setTimeout、Promise、async/await），虽然代码在同一个事件循环中执行，但如果单例的创建逻辑设计不当，在实例尚未完全创建完成时，另一个异步任务可能会尝试再次创建实例。
  2. Web Workers 环境下的实例隔离： 每个 Web Worker 都在一个独立的线程中运行，拥有自己的全局作用域。主线程的单例不会自动共享给 Web Worker，每个 Worker 都会有自己的实例。因此，实现跨 Worker 的单例需要更复杂的机制（通常涉及消息传递或 SharedArrayBuffer，但这超出了经典单例模式的范畴）。

本讲座将深入探讨如何在 JavaScript 中利用闭包、立即执行函数表达式（IIFE）和 ES Modules 来实现单例模式，并着重分析它们如何确保在 JavaScript 的执行模型下达到“单实例”和“线程安全”（在上述第一点意义上）的目的。

一、单例模式的核心原则与基础实现

单例模式的核心在于两点：

  1. 确保唯一性： 构造函数或创建逻辑只能被调用一次，以创建唯一的实例。
  2. 提供全局访问： 必须提供一个公共方法或属性，让所有需要使用该实例的代码都能获取到同一个实例。

让我们从一个简单的、但存在缺陷的单例实现开始，以此引出更健壮的方法。

1.1 基础实现（存在缺陷）

// 定义一个简单的 Logger 类
class Logger {
    constructor() {
        if (Logger.instance) {
            return Logger.instance; // 如果已存在实例，则直接返回
        }
        this.logs = [];
        console.log("Logger 实例被创建！");
        Logger.instance = this; // 存储当前实例
    }

    log(message) {
        const timestamp = new Date().toISOString();
        this.logs.push(`[${timestamp}] ${message}`);
        console.log(`Log: ${message}`);
    }

    getLogs() {
        return this.logs;
    }
}

// 尝试创建多个实例
const logger1 = new Logger();
const logger2 = new Logger();

console.log(logger1 === logger2); // true

logger1.log("这是第一条日志");
logger2.log("这是第二条日志");

console.log(logger1.getLogs());
console.log(logger2.getLogs());

分析：

这个实现通过在构造函数内部检查 Logger.instance 静态属性来确保唯一性。如果 Logger.instance 已经存在，则返回现有实例；否则，创建新实例并将其存储到 Logger.instance 中。

缺陷：

  1. 非私有实例变量： Logger.instance 是一个公共静态属性，外部可以直接访问甚至修改，这破坏了单例的封装性。
  2. 不是惰性加载： 即使构造函数内部有判断，但 new Logger() 每次都会执行，只是返回了同一个实例。
  3. 在某些特定异步场景下仍可能出现问题： 如果在实例尚未完全初始化（例如，constructor 中有异步操作），但 Logger.instance 已经被赋值之前，另一个 new Logger() 被调用，理论上可能导致问题。虽然在 JavaScript 的单线程模型下这种情况比较少见，但在更复杂的异步流程中，仍需更严谨的控制。

为了解决这些问题，我们需要利用 JavaScript 的闭包特性来创建私有作用域，从而更好地控制实例的创建和访问。

二、利用闭包实现单例模式

闭包是 JavaScript 中一个强大而核心的特性。当一个函数能够记住并访问其词法作用域，即使该函数在其词法作用域之外执行时，它就形成了一个闭包。我们可以利用闭包来创建一个私有变量来存储单例实例，并提供一个公共方法来获取它。

2.1 闭包实现原理

核心思想是：

  1. 定义一个外部函数，该函数内部包含一个私有变量来存储实例。
  2. 外部函数返回一个内部函数（通常命名为 getInstance），这个内部函数负责检查实例是否存在，如果不存在则创建，然后返回实例。
  3. 由于内部函数形成闭包，它能够持续访问外部函数的私有变量，从而维护实例的唯一性。

2.2 闭包实现示例

// 定义一个配置管理器
function ConfigManager() {
    let instance; // 私有变量，用于存储单例实例
    let config = {}; // 假设的配置数据

    // 内部构造函数，负责初始化实例
    function init() {
        // 模拟一些初始化操作
        console.log("ConfigManager 实例被初始化！");
        config = {
            apiUrl: "https://api.example.com",
            timeout: 5000,
            version: "1.0.0"
        };
        return {
            getConfig: () => config,
            setApiUrl: (url) => {
                config.apiUrl = url;
                console.log(`API URL 已更新为: ${url}`);
            },
            // 其他方法...
        };
    }

    // 公共方法，用于获取单例实例
    return {
        getInstance: function() {
            if (!instance) {
                instance = init(); // 如果实例不存在，则创建
            }
            return instance; // 返回唯一实例
        }
    };
}

// 获取 ConfigManager 的创建器
const configManagerCreator = ConfigManager();

// 通过创建器获取单例实例
const config1 = configManagerCreator.getInstance();
const config2 = configManagerCreator.getInstance();

console.log(config1 === config2); // true

console.log("配置1:", config1.getConfig());
config1.setApiUrl("https://newapi.example.com");
console.log("配置2:", config2.getConfig()); // 验证 config2 也反映了更改

分析：

  • ConfigManager 函数执行时，它创建了一个私有作用域，其中包含 instance 变量和 init 函数。
  • ConfigManager 返回一个对象 { getInstance: function() { ... } }。
  • getInstance 函数是一个闭包，它持续拥有对 instance 变量的访问权限。
  • 当第一次调用 configManagerCreator.getInstance() 时，instance 为 undefined，init() 函数被调用，创建并返回实际的配置对象，并将其赋值给 instance。
  • 后续调用 configManagerCreator.getInstance() 时，instance 已经存在，直接返回现有实例。

“线程安全”性（在 JavaScript 语境下）：

这种闭包实现方式在 JavaScript 的单线程环境中具有很好的“线程安全”性，因为它通过以下方式避免了多次实例化：

  • 私有变量隔离： instance 变量完全封装在 ConfigManager 函数的作用域内，外部无法直接访问或修改，从而保证了其私有性。
  • 惰性加载与原子性： init() 函数只有在第一次调用 getInstance() 时才会被执行。在 getInstance() 内部的 if (!instance) 判断和 instance = init() 赋值操作是原子性的（在同一个事件循环任务中完成）。这意味着，即使在异步环境中，只要 getInstance() 被调用，它会立即检查 instance 的状态，并确保 init() 只被调用一次。在 init() 执行期间，其他对 getInstance() 的调用将等待当前任务完成，然后再次检查 instance，此时 instance 已被赋值，直接返回。

三、利用立即执行函数表达式（IIFE）实现单例模式

立即执行函数表达式（Immediately Invoked Function Expression，IIFE）是 JavaScript 中一种常见的模式，它在定义后立即执行。IIFE 创建了一个独立的作用域，可以有效地隐藏内部变量，防止它们污染全局作用域。这使得 IIFE 成为实现单例模式的理想选择。

3.1 IIFE 实现原理

核心思想是：

  1. 将单例的创建逻辑封装在一个 IIFE 中。
  2. IIFE 内部定义私有变量（如 instance）和私有方法。
  3. IIFE 返回一个公共接口对象，其中包含 getInstance 方法。
  4. 由于 IIFE 在脚本加载时立即执行一次，它会立刻创建并返回一个单例工厂对象，这个工厂对象维护着私有的 instance 变量。

3.2 IIFE 实现示例

// 定义一个事件总线
const EventBus = (function() {
    let instance; // 私有变量，用于存储单例实例
    let subscribers = {}; // 存储事件订阅者

    // 内部构造函数，负责初始化实例
    function init() {
        console.log("EventBus 实例被初始化！");
        return {
            // 发布事件
            publish: function(eventName, data) {
                if (subscribers[eventName]) {
                    subscribers[eventName].forEach(callback => {
                        try {
                            callback(data);
                        } catch (error) {
                            console.error(`Error in event handler for ${eventName}:`, error);
                        }
                    });
                }
            },
            // 订阅事件
            subscribe: function(eventName, callback) {
                if (!subscribers[eventName]) {
                    subscribers[eventName] = [];
                }
                subscribers[eventName].push(callback);
                console.log(`Subscribed to ${eventName}`);
            },
            // 取消订阅
            unsubscribe: function(eventName, callback) {
                if (subscribers[eventName]) {
                    subscribers[eventName] = subscribers[eventName].filter(cb => cb !== callback);
                    console.log(`Unsubscribed from ${eventName}`);
                }
            },
            // 获取所有订阅者 (仅用于演示，实际可能不暴露)
            getSubscriberCount: () => Object.keys(subscribers).length
        };
    }

    // IIFE 返回的公共接口
    return {
        getInstance: function() {
            if (!instance) {
                instance = init(); // 如果实例不存在，则创建
            }
            return instance; // 返回唯一实例
        }
    };
})(); // 立即执行

// 获取单例实例
const bus1 = EventBus.getInstance();
const bus2 = EventBus.getInstance();

console.log(bus1 === bus2); // true

// 订阅事件
bus1.subscribe('userLoggedIn', (user) => {
    console.log(`用户 ${user.name} 已登录！`);
});

bus2.subscribe('userLoggedIn', (user) => {
    console.log(`欢迎 ${user.name} 再次回来！`);
});

bus1.subscribe('productAdded', (product) => {
    console.log(`产品 ${product.name} (ID: ${product.id}) 已添加到购物车。`);
});

// 发布事件
bus2.publish('userLoggedIn', { name: 'Alice', id: 123 });
bus1.publish('productAdded', { name: 'Laptop', id: 'P001' });

console.log("事件总线订阅者数量:", bus1.getSubscriberCount());

分析：

  • 整个单例逻辑被包裹在一个 (function() { ... })(); IIFE 中。
  • 当脚本加载时，IIFE 立即执行。它创建了私有变量 instance 和 subscribers，以及 init 函数。
  • IIFE 返回一个对象 { getInstance: function() { ... } }，并将其赋值给 EventBus 变量。
  • 后续对 EventBus.getInstance() 的调用与闭包实现类似，通过检查 instance 变量来确保 init() 只被调用一次。

“线程安全”性（在 JavaScript 语境下）：

IIFE 实现与闭包实现具有相同的“线程安全”特性：

  • 私有作用域： IIFE 创建了一个独立的作用域，instance 变量完全私有，不可从外部直接访问或修改。
  • 初始化时机与惰性加载： IIFE 在脚本加载时执行一次，但实际的单例对象 (init()) 仍然是惰性加载的，即只有在第一次调用 getInstance() 时才会被创建。这种机制确保了在单线程事件循环中，init() 逻辑只执行一次，从而防止了异步操作导致的多次实例化问题。

优势：

  • 隔离性更强： IIFE 立即执行并返回单例工厂，其内部所有变量（包括 instance）都只存在于 IIFE 的闭包作用域中，不会污染全局命名空间。
  • 代码简洁： 将单例的定义和获取封装在一起，使得代码结构更加紧凑。

四、利用 ES Modules 实现单例模式

ES Modules（ESM）是 JavaScript 官方的模块化标准，它在现代 JavaScript 开发中扮演着核心角色。ES Modules 的一个关键特性是模块在应用程序的生命周期中只会被加载和评估一次。当一个模块被多次导入时，它返回的是同一个模块实例的引用。这一特性使得 ES Modules 自然而然地成为实现单例模式的强大且推荐的方式。

4.1 ES Modules 实现原理

核心思想是：

  1. 创建一个独立的模块文件（例如 singletonService.js）。
  2. 在该模块内部直接创建并导出一个实例，或者导出一个工厂函数，该工厂函数在内部维护一个私有实例，并始终返回同一个实例。
  3. 应用程序中任何需要使用该单例的地方，只需导入该模块。由于模块的缓存机制，所有导入都将指向同一个实例。

4.2 ES Modules 实现示例

文件：loggerService.js

// loggerService.js
class Logger {
    constructor() {
        if (Logger._instance) { // 检查是否存在实例
            return Logger._instance;
        }
        this.logs = [];
        this.id = Math.random().toString(36).substring(2, 9); // 生成一个唯一ID用于演示
        console.log(`Logger 实例被创建，ID: ${this.id}`);
        Logger._instance = this;
    }

    log(message) {
        const timestamp = new Date().toISOString();
        this.logs.push(`[${timestamp}] ${message}`);
        console.log(`[ID:${this.id}] Log: ${message}`);
    }

    getLogs() {
        return this.logs;
    }
}

// 方式一：直接导出 Logger 类，并在需要时实例化（这种方式依赖调用者自己保证单例）
// export default Logger;

// 方式二：在模块内部创建实例并直接导出 (推荐，更符合ESM单例语义)
const instance = new Logger(); // 模块加载时立即创建实例
export default instance;

// 方式三：导出工厂函数，内部维护实例 (结合了惰性加载和ESM特性，但通常方式二更直接)
/*
let loggerInstance;
export function getLoggerInstance() {
    if (!loggerInstance) {
        loggerInstance = new Logger();
    }
    return loggerInstance;
}
*/

文件：main.js

// main.js
import logger from './loggerService.js'; // 导入模块的默认导出

logger.log("主模块：开始运行...");
logger.log("主模块：执行了一些操作...");

// 假设有一个辅助模块
import './helper.js';

logger.log("主模块：完成！");

// 访问日志
console.log("所有日志:", logger.getLogs());

文件：helper.js

// helper.js
import logger from './loggerService.js'; // 导入同一个 Logger 实例

logger.log("辅助模块：执行中...");
logger.log("辅助模块：处理了一些数据...");

运行方式：

由于使用了 ES Modules，你需要在支持模块的环境中运行此代码，例如：

  • 在 HTML 文件中通过 <script type="module" src="main.js"></script> 引入。
  • 使用 Node.js 运行（确保 package.json 中 "type": "module" 或使用 .mjs 扩展名）。

控制台输出示例：

Logger 实例被创建，ID: ...       // 只会创建一次
[ID:...] Log: 主模块：开始运行...
[ID:...] Log: 主模块：执行了一些操作...
[ID:...] Log: 辅助模块：执行中...
[ID:...] Log: 辅助模块：处理了一些数据...
[ID:...] Log: 主模块：完成！
所有日志: [...]

分析：

  • 当 main.js 导入 loggerService.js 时，loggerService.js 模块会被加载并执行一次。
  • 在 loggerService.js 内部，const instance = new Logger(); 会被执行，创建一个 Logger 的实例。
  • 这个实例被 export default instance; 导出。
  • 当 helper.js 也导入 loggerService.js 时，JavaScript 模块加载器会识别出 loggerService.js 已经被加载过，因此它不会再次执行模块代码，而是直接返回第一次加载时缓存的导出对象（即那个唯一的 Logger 实例）。
  • 因此，main.js 和 helper.js 中的 logger 变量都指向同一个 Logger 实例。

“线程安全”性（在 JavaScript 语境下）：

ES Modules 是实现 JavaScript 单例模式最自然、最健壮且最“线程安全”的方式之一，原因在于其底层机制：

  • 模块加载和缓存机制： ESM 规范明确规定，一个模块在整个应用程序的生命周期中只会被加载和评估一次。首次导入时，模块代码执行，导出的值被计算并缓存。后续所有对同一模块的导入都将返回这个缓存的值。这从根本上保证了模块内部创建的单例实例的唯一性。
  • 避免异步竞态： 模块的加载和评估过程本身是同步的（或在异步加载完成后，其评估过程是原子性的）。一旦模块被评估，其导出的单例就确定了。这消除了在异步操作中因多次尝试实例化而导致的竞态条件。
  • 明确的依赖管理： import 和 export 语法提供了清晰的依赖关系，易于理解和维护。

局限性：

  • Web Workers 隔离： 尽管 ES Modules 在单个“realm”（如主线程）中提供单例行为，但每个 Web Worker 都有其独立的模块环境。如果在主线程和 Web Worker 中都导入同一个单例模块，它们将各自拥有一个独立的实例。要实现跨 Worker 的共享单例，需要更复杂的通信或共享内存机制。
  • 不适用于传统 <script> 标签： ESM 需要通过 type="module" 或 Node.js 模块环境来运行。

五、高级考量与 JavaScript 中的“线程安全”深度解析

5.1 JavaScript 的并发模型与“线程安全”的独特视角

理解 JavaScript 中单例模式的“线程安全”性，必须深入理解 JavaScript 的并发模型：

  • 单线程事件循环： JavaScript 在浏览器和 Node.js 环境中，其主线程都是单线程的，通过事件循环（Event Loop）来处理任务。这意味着在任何给定时间点，只有一段 JavaScript 代码在执行。因此，传统意义上的“多个线程同时修改同一块内存”的竞态条件在主线程中是不存在的。
  • 异步操作与任务队列： JavaScript 通过异步编程来处理耗时操作（如网络请求、定时器、用户交互）。这些异步操作完成后，它们的回调函数会被放入任务队列（或微任务队列），等待事件循环空闲时执行。
  • “线程安全”的侧重点： 在 JavaScript 主线程中，单例的“线程安全”主要关注的是：
    1. 防止在异步回调中重复实例化： 如果一个单例的 getInstance 方法在异步操作（如 fetch 请求返回后）中被多次调用，并且其内部的 instance 检查和赋值逻辑不能正确处理，就可能导致多次实例化。我们前面讨论的闭包、IIFE 和 ESM 模式都通过私有变量和原子性的判断/赋值操作有效地解决了这个问题。
    2. 模块评估的唯一性： ESM 模式的“线程安全”性直接来源于其模块加载器保证模块代码只评估一次的机制。

5.2 惰性初始化与饿汉式初始化

  • 惰性初始化（Lazy Initialization）： 实例在第一次被需要时才创建。

    • 优点： 节省资源，如果实例从未使用，则不会占用内存。
    • 缺点： 首次使用时可能存在轻微的延迟，初始化逻辑需要有线程安全保障（我们前面讨论的闭包和 IIFE 结合 getInstance 方法就是惰性加载的）。
    • 示例： 闭包和 IIFE 模式中，init() 函数只有在 getInstance() 第一次被调用时才执行。

  • 饿汉式初始化（Eager Initialization）： 实例在应用程序启动时（或模块加载时）就创建。

    • 优点： 实例随时可用，没有首次使用时的延迟。
    • 缺点： 即使实例从未使用，也会占用资源。
    • 示例： ES Modules 模式中，如果直接导出 const instance = new Logger();，那么 Logger 实例在模块加载时就创建了。

选择哪种方式取决于具体需求。对于资源消耗较小或立即需要使用的单例，饿汉式可能更简单直接。对于资源消耗大且不确定是否会被使用的单例，惰性初始化更合适。

5.3 Web Workers 与跨线程单例

如前所述，Web Workers 在独立的线程中运行，每个 Worker 都有自己的全局作用域和模块加载环境。这意味着：

// main.js
import singleton from './mySingleton.js';
singleton.setValue(1);
console.log('Main thread singleton value:', singleton.getValue()); // 1

const worker = new Worker('worker.js', { type: 'module' });
worker.postMessage('request_value');
// worker.js
import singleton from './mySingleton.js';
singleton.setValue(2); // 这会修改worker自己的单例实例，而不是主线程的
console.log('Worker singleton value:', singleton.getValue()); // 2

self.onmessage = (e) => {
    if (e.data === 'request_value') {
        self.postMessage(singleton.getValue()); // 发送worker的单例值
    }
};
// mySingleton.js (示例)
let _value = 0;
class MySingleton {
    constructor() {
        if (MySingleton._instance) return MySingleton._instance;
        MySingleton._instance = this;
    }
    setValue(val) { _value = val; }
    getValue() { return _value; }
}
export default new MySingleton();

结果： 主线程和 Worker 将各自拥有一个 MySingleton 实例，它们的值是独立的。

要实现真正的跨 Web Worker 共享单例状态，你需要：

  • 消息传递： 将其中一个线程作为“主”单例，其他线程通过 postMessage 和 onmessage 与其通信，请求或更新状态。
  • SharedArrayBuffer 和 Atomics： 这是 JavaScript 中唯一提供共享内存和原子操作的机制，可以用于在不同 Worker 之间共享和同步低级数据。但这种方式实现复杂，通常用于高性能计算，而不是简单的单例模式。

因此，对于绝大多数 JavaScript 单例模式的讨论，我们主要关注在单个主线程（或单个 Web Worker 内部）如何保证实例的唯一性，以及防止异步操作导致的重复实例化。

六、单例模式的实际应用场景

  • 配置管理器 (Configuration Manager)： 整个应用只需要一个配置对象，负责加载和提供应用配置。
  • 日志记录器 (Logger)： 所有的日志信息都应该通过同一个日志实例来记录，确保日志的统一输出和管理。
  • 事件总线 (Event Bus / PubSub)： 应用中的所有组件通过同一个事件总线来发布和订阅事件，实现解耦通信。
  • 状态管理器 (State Manager)： 简单的全局状态管理，例如一个用于存储用户登录状态的 Store。
  • 数据库连接池 (Database Connection Pool)： 在 Node.js 后端应用中，通常只需要一个数据库连接池实例来管理所有数据库连接。
  • 缓存管理器 (Cache Manager)： 统一管理应用内的数据缓存。

七、单例模式的优缺点

7.1 优点

  • 资源节约： 避免了重复创建对象，尤其是对于那些创建开销大、或需要占用大量系统资源的实例（如数据库连接、网络连接）。
  • 全局访问点： 提供了一个明确的、唯一的全局访问点，方便所有模块使用。
  • 统一管理： 确保所有操作都通过同一个实例进行，便于控制和协调（如日志、配置）。
  • 延迟初始化： 可以实现惰性加载，只在第一次需要时才创建实例。

7.2 缺点

  • 紧耦合与测试困难： 单例模式引入了全局状态，使得代码模块之间产生隐式依赖，增加了模块间的耦合度。这使得单元测试变得困难，因为每次测试都需要一个干净的、独立的单例实例。
  • 违反单一职责原则： 单例类不仅要负责其核心业务逻辑，还要负责控制自身的唯一实例化，这违反了单一职责原则。
  • 隐藏依赖： 客户端代码直接通过全局访问点获取单例，而不是通过构造函数或参数注入，这使得依赖关系不那么明显，增加了代码的复杂性和理解难度。
  • 过度使用： 很容易被滥用，将本不应该全局化的对象设计成单例，导致系统变得僵硬和难以扩展。

八、替代方案与何时避免使用单例

考虑到单例模式的缺点，尤其是在现代 JavaScript 开发中，我们常常有更好的替代方案：

  • 依赖注入 (Dependency Injection, DI)： 将依赖作为参数传递给构造函数或方法，而不是通过全局访问点获取。这极大地提高了代码的可测试性和模块化。
  • 工厂模式 (Factory Pattern)： 如果你需要控制对象的创建过程，但并不限制只有一个实例，工厂模式是更好的选择。
  • ES Modules 的自然单例： 对于许多场景，ES Modules 的默认行为（模块只评估一次）已经足够满足“单实例”的需求，无需额外编写复杂的单例模式代码。直接导出一个对象或一个函数，然后在需要的地方导入即可。
  • 组件化与状态管理库： 在前端框架（如 React, Vue）中，全局状态管理通常通过专门的状态管理库（如 Redux, Vuex）来实现，这些库提供了更结构化、可预测和可测试的方式来管理全局状态，而不是依赖于手写的单例。

何时避免使用单例：

  • 当对象不需要严格限制为唯一实例时。
  • 当对象状态是局部的，不应被全局共享时。
  • 当需要高可测试性，希望轻松模拟和替换依赖时。
  • 当依赖关系应该显式声明而不是隐式获取时。

九、关于 JavaScript 单例模式的几点总结

在 JavaScript 中，单例模式是一种确保类只有一个实例并提供全局访问点的设计模式。通过利用闭包、IIFE 或 ES Modules，我们可以有效地实现这一目标。其中，ES Modules 因其模块加载机制的天然优势，是现代 JavaScript 中实现单例模式最简洁、最健壮且最推荐的方式。

理解 JavaScript 的单线程事件循环机制对于理解单例模式的“线程安全”性至关重要。这里的“线程安全”主要指防止在异步操作中重复实例化，而非传统多线程环境下的内存同步问题。对于 Web Workers 这种真正的多线程环境，标准的单例模式无法跨线程共享实例，需要额外的通信或共享内存机制。在权衡其优缺点后，我们应谨慎选择单例模式，并在有更优替代方案时优先考虑它们。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注