本文解析为何仅靠闭包共享状态（如 counter）不构成单例模式，并演示如何通过延迟初始化与实例缓存实现符合定义的真正单例。
本文解析为何仅靠闭包共享状态（如 `counter`）不构成单例模式，并演示如何通过延迟初始化与实例缓存实现符合定义的真正单例。
单例模式的核心契约是：全局范围内有且仅有一个类的实例，所有获取操作必须返回同一个对象引用。它不是“行为一致”或“状态共享”的代名词——而恰恰是“实例同一性”（identity）的保证。
在原始代码中，每次调用 getInsctance() 都会执行 createInstance()，创建一个全新对象：
const createInstance = () => ({
getCounter: () => counter,
addCounter: (num) => counter += num,
});虽然 counter 变量被闭包捕获、所有对象共用同一份状态，但 r 和 r2 实际指向两个不同的对象：
console.log(r === r2); // false ← 关键证据！
这违反了单例的本质：单例要求 r === r2 恒为 true。当前实现只是“共享状态的工厂函数”，而非单例。
✅ 正确做法是：只在首次调用时创建实例，并缓存该实例；后续调用直接返回缓存引用。关键修改如下：
- 移除闭包中的 counter，将其作为实例自身的属性；
- 使用普通函数（非箭头函数），使 this 正确绑定到实例；
- 在 getInstance 中使用 instance || (instance = createInstance()) 实现惰性初始化与复用。
修正后的标准单例实现如下：
const singleton = (function() {
let instance;
const createInstance = () => ({
counter: 0,
getCounter() {
return this.counter;
},
addCounter(num) {
this.counter += num;
return this; // 支持链式调用（可选）
}
});
return {
getInstance: () => instance || (instance = createInstance())
};
})();
// 验证实例唯一性
const r = singleton.getInstance();
const r2 = singleton.getInstance();
console.log(r === r2); // true ✅
r.addCounter(12);
r2.addCounter(32);
console.log(r.getCounter()); // 44
console.log(r2.getCounter()); // 44（因同一实例）
// 注意：singleton.counter = 100 无效 —— singleton 对象本身无 counter 属性
// 所有状态均封装在实例内部，外部无法意外篡改⚠️ 重要注意事项：
- 箭头函数禁用 this 绑定：若方法写成 () => this.counter，this 将指向外层作用域（通常是 undefined），导致逻辑失效；
- 避免暴露内部状态：不要将 counter 提升为模块级变量或挂载到单例对象上，否则破坏封装性与线程/并发安全性（在 Node.js 多实例场景下尤为关键）；
- 单例 ≠ 全局状态容器：如答案中强调，计数器通常应支持多个独立实例（例如不同业务模块各需一个计数器）。滥用单例会导致隐式耦合、难以测试和不可预测的副作用。
总结：单例模式的判定依据永远是 === 相等性，而非行为一致性。真正可靠的单例必须同时满足：① 构造可控（仅一次实例化）、② 引用唯一（始终返回同一对象）、③ 状态自治（数据属于实例自身）。遵循这三点，才能写出可维护、可验证、符合设计原则的单例实现。
