JavaScript单例应优先用ES模块默认导出实现，因其依赖模块缓存机制天然唯一；次选闭包缓存工厂函数；Class写法需禁用new并警惕跨chunk实例分裂。
JavaScript 中能稳定落地的单例模式，核心就一条：**用闭包或模块作用域控制实例唯一性，别依赖 new 关键字本身**。直接写 class Singleton 然后靠构造函数拦截，多数场景反而埋坑。
为什么不能靠 constructor 拦截来实现单例？
很多人第一反应是“在构造函数里判断 this._instance”，但问题在于：new 每次都会创建新对象，this 不是共享的；而静态属性又可能被外部篡改或跨模块失效（尤其在 ESM 环境下）。
-
Singleton.getInstance()是可靠入口，new Singleton()应该被禁止或抛错 - ESM 的模块缓存机制天然支持单例，比手动管理
_instance更轻量、更安全 - 如果用了打包工具（如 Webpack/Vite），多次
import同一模块，仍指向同一模块实例 —— 这才是 JS 单例最自然的底座
最简可行的单例：ES 模块 + 默认导出
不写 class，不搞私有字段，靠模块顶层作用域天然单例。适用于配置、日志器、状态管理器等轻量全局服务。
const logger = {
logs: [],
log(msg) {
this.logs.push(`[${new Date().toISOString()}] ${msg}`);
console.log(msg);
}
};
export default logger;
所有地方 import logger from './logger.js' 拿到的都是同一个对象引用。无需额外逻辑，无兼容性问题，无内存泄漏风险。
立即学习“Java免费学习笔记（深入）”；
需要延迟初始化时：工厂函数 + 闭包缓存
当单例依赖异步资源（如 API 初始化）、或创建开销大、且不希望模块加载时就执行，用闭包缓存更可控。
let instance = null;
function createDatabaseConnection() {
// 模拟耗时初始化
return { query(sql) { return `result from ${sql}`; } };
}
export function getDB() {
if (!instance) {
instance = createDatabaseConnection();
}
return instance;
}
- 调用
getDB()多次，返回同一对象 -
instance在模块作用域内，外部无法直接修改 - 注意：若
createDatabaseConnection抛错，当前实现会重复执行 —— 生产中应加错误标记（如instance = { error: err }）避免无限重试
Class 写法的单例：只暴露静态方法，禁用 new
如果团队强依赖 class 语法，必须确保构造不可见。常见错误是把 getInstance 写成实例方法，或允许 new 成功。
class ConfigManager {
constructor() {
if (ConfigManager.instance) {
throw new Error('Use ConfigManager.getInstance() instead of new');
}
this.data = {};
}
static getInstance() {
if (!ConfigManager.instance) {
ConfigManager.instance = new ConfigManager();
}
return ConfigManager.instance;
}
set(key, value) {
this.data[key] = value;
}
}
// 静态属性在模块级有效，但需注意：Webpack 的 scope hoisting 可能导致多个 chunk 中的 ConfigManager.instance 不共享
export default ConfigManager;
真正麻烦的点不在写法，而在多入口、微前端、动态 import() 场景下，ConfigManager.instance 可能出现多个副本 —— 这时候模块级单例（前两种）反而更稳。
单例最难的不是“怎么写”，而是“在哪用”：它会让测试变难、隐藏依赖、阻碍并发隔离。真要用，优先选模块默认导出；非得 class，就别让 new 成功；所有方案都要警惕跨 chunk / 跨沙箱环境的实例分裂。
