JavaScript单例模式核心是确保类唯一实例并提供全局访问点，常用闭包工厂函数、ES6类静态属性或对象字面量实现，适用于状态管理、日志、SDK封装等场景。
JavaScript 中实现单例模式的核心是：**确保一个类只有一个实例，并提供全局访问点**。由于 JS 没有原生的类实例控制机制（如 Java 的 private 构造器），我们靠闭包、模块作用域或静态属性来“封住”重复创建的路径。
常见实现方式
1. 简单对象字面量（最轻量，适合配置/工具对象）
直接定义一个对象，天然唯一：
const Config = {
apiUrl: 'https://api.example.com',
timeout: 5000,
setEnv(env) {
this.env = env;
}
};
✅ 优点：简洁、无初始化逻辑；❌ 缺点：无法延迟初始化，不支持构造参数。
2. 闭包 + 工厂函数（推荐，支持懒加载和参数）
用闭包保存实例，首次调用才创建：
立即学习“Java免费学习笔记（深入）”；
function createLogger(name) {
let instance;
return function() {
if (!instance) {
instance = {
name,
log(msg) { console.log(`[${this.name}]: ${msg}`); }
};
}
return instance;
};
}
const getLogger = createLogger('main');
const logger1 = getLogger(); // 创建
const logger2 = getLogger(); // 返回同一实例
console.log(logger1 === logger2); // true
3. ES6 Class + 静态属性（语义清晰，现代写法）
在类上挂载私有静态实例，用 getter 控制访问：
class Database {
constructor(url) {
if (Database.instance) {
return Database.instance;
}
this.url = url;
this.connection = null;
Database.instance = this;
}
connect() {
if (!this.connection) {
this.connection = `Connected to ${this.url}`;
}
return this.connection;
}
}
// 使用时需注意：new Database() 每次都返回同一个实例
const db1 = new Database('mysql://localhost');
const db2 = new Database('redis://localhost'); // url 被忽略，仍返回 db1
⚠️ 注意：这种写法中后续构造参数无效，更适合无参或参数一致的场景。若需不同参数初始化，应改用工厂函数封装。
一套面向小企业用户的企业网站程序！功能简单，操作简单。实现了小企业网站的很多实用的功能，如文章新闻模块、图片展示、产品列表以及小型的下载功能，还同时增加了邮件订阅等相应模块。公告，友情链接等这些通用功能本程序也同样都集成了！同时本程序引入了模块功能，只要在系统默认模板上创建模块，可以在任何一个语言环境（或任意风格）的适当位置进行使用！
典型应用场景
状态管理器（如轻量级 Store）
整个应用只需一个状态容器，避免多处冗余维护：
- 全局用户登录状态（userInfo、token、权限列表）
- 主题配置（darkMode、fontSize、language）
- 不需要 Redux/Vuex 时的小型项目状态中枢
日志记录器（Logger）
统一格式、等级、输出目标（控制台/上报服务），避免多个 logger 冲突或重复初始化：
- 自动添加时间戳、模块名前缀
- 集中控制日志开关（dev-only）、采样率
- 避免每个组件 new Logger() 造成资源浪费
第三方 SDK 实例封装（如支付、地图、埋点）
SDK 初始化开销大，且多数只允许一个实例：
- 微信 JSSDK 的 wx 对象需通过 config 初始化一次
- 高德地图 AMap.Map 实例通常按容器 ID 单例管理
- 埋点 SDK（如神策、GrowingIO）暴露的 sa 对象本身就是单例
浏览器 API 封装（如 Notification、WebSocket 连接池）
防止重复请求或连接：
- 全局 WebSocket 管理器：统一处理重连、心跳、消息分发
- 通知中心：聚合所有业务通知，避免弹窗打架
- 音频上下文（AudioContext）—— 浏览器建议复用，而非多次 new
注意事项与替代思路
单例虽实用，但易导致隐式依赖、难以单元测试、状态污染。实际开发中可考虑：
- 优先用模块顶层变量（ESM 默认单例）：import 同一文件即得同一对象
- 用依赖注入（如框架中的 provide/inject）代替硬编码单例
- 对需要多实例的场景（如多个 WebSocket 地址），改用“注册表模式” + key 索引
基本上就这些。单例不是银弹，关键在“是否真需要全局唯一且共享状态”。用对了省事，滥用则埋坑。
