JavaScript中实现单例模式的核心是确保一个类仅有一个实例并提供全局访问点，常用es6类结合静态方法实现，通过静态属性保存实例并提供getInstance方法获取唯一实例，如AppConfig类所示；此外还可利用闭包与IIFE将实例私有化，确保外部无法直接访问，或利用ES模块特性导出实例，因模块只加载一次从而天然实现单例；该模式适用于配置管理、日志记录、全局弹窗等需唯一实例的场景，能避免资源浪费和状态冲突；但需注意其带来的测试困难、全局状态副作用、模块间隐式耦合及过度使用导致的扩展困难等问题，在大型项目中应谨慎使用以保障代码可维护性与可测试性。
在JavaScript里实现单例模式，核心就是确保一个类或对象在任何时候都只有一个实例，并且提供一个全局访问点，让所有需要的地方都能获取到这个唯一的实例。这通常用于管理共享资源或全局状态，比如配置对象、日志记录器或者一个应用里唯一的弹窗管理器。
解决方案
实现一个简单的单例模式，我们可以利用JavaScript的闭包特性和模块化思想。这里提供一个基于ES6 class和静态方法的实现，它在现代前端开发中比较常见：
class AppConfig { constructor() { // 检查是否已经存在实例 if (AppConfig.instance) { return AppConfig.instance; } // 如果不存在，则创建并保存实例 AppConfig.instance = this; this.settings = { theme: 'dark', language: 'zh-CN', version: '1.0.0' }; console.log('AppConfig: 实例已初始化。'); } getSetting(key) { return this.settings[key]; } setSetting(key, value) { this.settings[key] = value; console.log(`AppConfig: 设置 ${key} 为 ${value}`); } static getInstance() { if (!AppConfig.instance) { AppConfig.instance = new AppConfig(); } return AppConfig.instance; } } // 示例用法： const config1 = AppConfig.getInstance(); const config2 = AppConfig.getInstance(); console.log(config1 === config2); // 输出：true，证明是同一个实例 config1.setSetting('theme', 'light'); console.log(config2.getSetting('theme')); // 输出：light
JavaScript单例模式在实际开发中有什么用？
单例模式在日常的javascript开发中，其实有不少挺实用的场景。我个人觉得，它主要解决的是“唯一性”和“全局访问”的问题。
一个很典型的例子是配置管理。想象一下，你的应用需要一套全局的配置，比如API地址、主题颜色、用户偏好设置等等。你肯定不希望每次用到配置的时候都去重新加载或者创建，那样既浪费资源又容易出错。这时候，一个单例的配置管理器就能派上用场了，它只加载一次配置，然后所有模块都能通过它来获取最新的配置信息。
再比如日志记录器。在一个复杂的应用里，你可能需要在不同的组件、不同的模块里记录日志。如果每个地方都自己创建一个日志实例，那日志的输出格式、目标（是控制台还是服务器）就很难统一管理。一个单例的日志记录器就能确保所有的日志都通过同一个入口输出，方便统一处理和分析。
还有一些ui相关的场景，像全局的弹窗管理器或者消息提示组件。你肯定不希望用户操作时，屏幕上同时弹出好几个相同的提示框吧？通过单例模式，你可以确保任何时候都只有一个活跃的弹窗或消息提示在屏幕上，避免界面混乱。
我个人觉得，这些场景下，单例模式能省不少心，避免重复创建资源，或者不同地方的数据打架，让代码逻辑更清晰。
除了ES6类，还有哪些JavaScript单例模式的实现技巧？
当然，除了上面提到的ES6类和静态方法，JavaScript作为一门灵活的语言，实现单例模式的方法远不止一种。有些老牌的技巧在现在也依然很有借鉴意义，甚至在特定场景下更优雅。
一个非常经典的实现是利用闭包（Closure）和立即执行函数表达式（IIFE）。这种方式在ES6之前很流行，它巧妙地利用了闭包来“私有化”实例变量，只暴露一个公共的获取实例的方法。
const Logger = (function() { let instance; // 这个变量被闭包“私有化”了 function createInstance() { const logger = { logs: [], log: function(message) { this.logs.push(`[${new Date().toISOString()}] ${message}`); console.log(`LOG: ${message}`); }, getLogs: function() { return this.logs; } }; return logger; } return { getInstance: function() { if (!instance) { instance = createInstance(); } return instance; } }; })(); // 示例用法： const logger1 = Logger.getInstance(); const logger2 = Logger.getInstance(); logger1.log('User logged in.'); logger2.log('Data fetched.'); console.log(logger1.getLogs()); // 包含两条日志，证明是同一个实例
这种方式的优点是，
instance
变量完全无法从外部直接访问，安全性更高。
另外，在现代JavaScript中，ES Modules（ESM）本身就提供了一种天然的单例实现方式。每个模块在应用中只会被加载和执行一次。如果你在一个模块中导出一个类的实例，那么无论在多少个地方导入这个模块，它们都将引用同一个实例。
// configservice.JS class ConfigService { constructor() { console.log('ConfigService: 实例已初始化 (通过模块导入)。'); this.settings = { apiKey: 'abc123xyz' }; } getApiKey() { return this.settings.apiKey; } } export default new ConfigService(); // 直接导出实例
// moduleA.js import config from './configService.js'; console.log('Module A API Key:', config.getApiKey());
// moduleB.js import config from './configService.js'; console.log('Module B API Key:', config.getApiKey());
这种模块模式的实现，我个人觉得是目前最推荐的，因为它利用了JavaScript语言和生态系统自带的特性，代码也最简洁明了。
使用JavaScript单例模式时需要注意哪些‘坑’？
虽然单例模式在某些场景下非常方便，但它也不是万能药，用不好反而会挖坑。我在实际项目中遇到过一些问题，觉得有必要提一下。
首先，一个比较大的“坑”是测试性问题。因为单例模式创建的是一个全局可访问的唯一实例，它会引入全局状态。这在进行单元测试时会变得很麻烦。比如，如果你在一个测试用例中修改了单例的状态，这个修改可能会影响到其他测试用例，导致测试结果不稳定或者难以复现。你可能需要为每个测试用例手动重置单例的状态，这增加了测试的复杂性。
其次，单例模式可能会导致隐藏的依赖和耦合。当多个模块都直接通过
getInstance()
来获取同一个单例时，它们之间就建立了一种隐式的、全局的依赖关系。一旦这个单例的内部实现或者状态发生变化，所有依赖它的模块都可能受到影响，而且这种影响往往很难追踪。这和“面向接口编程”或者“依赖注入”的思想是有些背离的，它让模块之间的边界变得模糊。
还有一个常见的误区是过度使用。不是所有需要“唯一”的东西都适合用单例模式。比如，你可能有一个“用户管理器”，但每个用户都应该有自己的实例，而不是所有用户共享一个“用户”单例。滥用单例模式可能导致代码变得僵硬，难以扩展和维护。当需求变化时，如果需要创建多个实例，或者需要对实例进行不同的配置，单例模式就会成为一个障碍。
最后，虽然JavaScript是单线程的，但其异步操作的特性，以及在Node.js等多进程环境下的应用，也需要注意。虽然单例的创建过程通常是同步的，但在非常复杂的异步场景下，或者在涉及到多个进程共享资源时（比如通过IPC通信），单例模式的实现可能需要更复杂的同步机制来保证其唯一性和状态一致性。不过，对于浏览器端的普通应用来说，这方面的问题通常不太突出。
我个人在用单例的时候，会特别小心它的副作用，尤其是在大型项目里，宁可多传几个参数，或者使用更明确的依赖注入方式，也不想引入一个难以追踪的全局状态。毕竟，代码的可维护性和可测试性，往往比一时的方便更重要。
