闭包单例比class static更适合弹窗管理，因其支持延迟初始化、避免全局污染、严格保证唯一性，且天然隔离作用域、防篡改、易测试、ssr友好。
闭包单例为什么比 class static 更适合弹窗管理
因为弹窗管理器需要延迟初始化（用户首次调用才创建）、避免全局污染、且必须严格保证实例唯一性——class 的 static 属性在模块热更新或多次 import 时可能被重复初始化，而闭包天然隔离作用域，只要模块不重载，内部变量就只初始化一次。
关键点在于：闭包的私有变量 instance 不会被外部篡改，且构造逻辑完全受控。
- 弹窗管理器通常依赖 DOM（如
document.body），必须等页面加载后才能安全创建，闭包可配合工厂函数实现按需触发 - 若用
class+static instance，测试时 mock 难度高；闭包返回的对象无原型链干扰，更容易 stub 或 reset - ESM 环境下，同一模块多次
import仍共享同一个闭包作用域，但class的static在某些打包器（如 Vite dev 模式）中可能意外重建
标准闭包单例写法及防误用要点
核心结构是「立即执行函数 + 私有变量 + 工厂方法」。不能直接暴露构造函数，也不能让外部能重新赋值 instance。
const ModalManager = (function () {
let instance = null;
<p>function createInstance() {
return {
modals: [],
open(options) { /<em> ... </em>/ },
close(id) { /<em> ... </em>/ },
destroyAll() { /<em> ... </em>/ }
};
}</p><p>return {
getInstance() {
if (!instance) {
instance = createInstance();
}
return instance;
}
};
})();</p><p>// 使用
const manager1 = ModalManager.getInstance();
const manager2 = ModalManager.getInstance();
console.log(manager1 === manager2); // true
</p>
- 必须把
instance声明在 IIFE 内部，不可提升到外层作用域 -
getInstance()不能接受参数（否则破坏单例语义），初始化逻辑应放在createInstance()内部处理 - 不要导出
createInstance，否则用户可绕过单例直接 new 多个实例 - 如果弹窗依赖异步资源（如 i18n 翻译），应在
getInstance()内做 Promise 缓存，而非每次调用都 fetch
如何支持 SSR 和服务端渲染兼容
Node.js 环境没有 document，直接执行 createInstance() 会报错。闭包单例必须检测运行时环境，延迟真正初始化。
常见错误是：在模块顶层就调用 document.createElement，导致 SSR 报 ReferenceError: document is not defined。
- 所有 DOM 操作必须收口到
getInstance()内部，且加typeof window !== 'undefined'判断 - 服务端应返回一个「哑对象」（stub），只保留方法签名，实际调用时静默忽略或 throw 提示
- 若使用 React，可在自定义 Hook（如
useModalManager()）里调用getInstance()，确保只在客户端执行
function createInstance() {
if (typeof window === 'undefined') {
return {
open() { console.warn('ModalManager not available in SSR'); },
close() {},
destroyAll() {}
};
}
// 正常 DOM 初始化逻辑...
}
调试时怎么确认真只有一个实例
最直接的方式是给实例打唯一标记，而不是依赖 === 判断——因为对象引用比较在跨 iframe 或跨模块时可能失效。
更可靠的做法是在闭包内生成一个不可枚举、不可配置的标识符，并暴露检查方法。
- 在
createInstance()中添加Object.defineProperty(instance, '_uid', { value: Math.random().toString(36).slice(2, 9), enumerable: false }) - 提供
isSingleton()方法，遍历已知可能的访问入口（如window.__modalManagerDebug）比对_uid - 开发环境可监听
getInstance()调用次数，超过 1 次就console.warn提示潜在滥用
容易被忽略的是：某些 UI 库（如 Ant Design）的 Modal.xxx() 方法内部也用了闭包单例，如果你的管理器和它混用，可能产生两个独立栈——这时要明确边界，要么封装它，要么放弃接管底层渲染。
