说实话，设计模式这东西，听起来总是带着一股“学院派”的酸腐味。尤其是对于咱们天天在业务代码里摸爬滚打的前端开发者来说23种设计模式，Neng叫得上名字的没几个，真Neng用得上的geng是少之又少。但是单例模式绝对是个例外。它就像是设计模式界的“Hello World”，简单到让人怀疑它存在的价值，却又在无数个大型项目中默默地支撑着核心逻辑。

今天咱们不搞那些虚头巴脑的定义，也不去背那些枯燥的教科书条文。我想带你走一条稍微不一样的路——一条渐进式的学习路径。咱们从直觉出发，一步步拆解，kankan这个kan似简单的模式，到底藏着什么玄机，以及为什么你可Neng在不知不觉中Yi经用了它无数次。

第一步：直觉先行——为什么我们需要“唯一”？

在写代码之前，先闭上眼睛想一想，在现实世界里有哪些东西是“只Neng有一份”的？

我想到了几个例子：你的身份证号码、你正在使用的这台电脑的操作系统内核、或者是一个国家在某一时刻的总统。Ru果这些东西突然变成了多份，世界大概就要乱套了。

回到前端开发，场景其实也是一样的。你有没有遇到过这种情况：用户手抖，疯狂点击一个按钮，结果页面上弹出了好几个一模一样的“登录弹窗”？或者，你在不同的组件里dou去请求了一次配置接口，结果导致后端服务器压力倍增？

这时候，你心里大概会冒出一个念头：“这东西，全系统里只要有一份就够了多了反而添乱。”

恭喜你，这就是单例模式的核心思想。它不是什么高深的算法，而是一种对“资源”和“状态”的管理哲学。它的核心诉求非常朴素：保证一个类只有一个实例，并提供一个全局访问点。

别小kan这句话，它解决的是两个大问题：一是节省资源，二是统一状态。

第二步：从闭包开始——Zui原始的“懒汉”

在JavaScript里要实现“只创建一次”，Zui直觉的手段就是利用闭包。咱们先kan一段非常基础的代码，别嫌弃它简单，这可是万丈高楼的地基。

let uniqueInstance = null;
function getSingleton {
  // 第一次进来的时候，这货肯定是空的
  if  {
    uniqueInstance = {
      createdAt: Date.now,
      data: '我是那个唯一的实例'
    };
    console.log;
  } else {
    console.log;
  }
  return uniqueInstance;
}
const a = getSingleton;
const b = getSingleton;
console.log; // true，毫无疑问，它们是同一个对象

kan到没？这就是所谓的“懒汉式”单例。什么叫“懒”？就是不到万不得Yi不动手。只有当你真正调用 `getSingleton` 的时候，它才会去检查有没有实例，没有才去创建。

这种写法它真的够用了。

不过你也别高兴得太早。这种写法有个小毛病，那个 `uniqueInstance` 变量是挂在外面的，虽然函数外面访问不到，但总觉得不够优雅，像是把钥匙藏在了门口的地垫下面。

第三步：进阶封装——把秘密藏在闭包里

为了不让那个变量污染全局，咱们Ke以用一个高阶函数把它包起来。这样，外部世界就彻底碰不到那个实例变量了只Neng通过你暴露出来的函数去拿。

function createSingletonManager {
  let instance = null;
  return function {
    if  {
      instance = {
        count: 0,
        add {
          this.count++;
        }
      };
    }
    return instance;
  };
}
const getInstance = createSingletonManager;
const s1 = getInstance;
const s2 = getInstance;
s1.add;
console.log; // 1，因为它们共享状态

这种写法是不是感觉稍微“高级”了一点？这就是利用闭包的特性，把 `instance` 变成了私有变量。除了通过 `getInstance` 这个函数，谁也别想动它。这种模式在前端里经常用来Zuo一些轻量级的全局状态管理，比如存储一些用户信息或者临时的配置项。

第四步：面向对象的诱惑——类的静态写法

Ru果你是从Java或者C#转过来的，或者你特别迷恋Class的写法，那么单例模式还有一套geng“正统”的西装。这套西装利用了类的静态属性。

class GlobalDialog {
  constructor {
    // 这一步是关键：Ru果实例Yi经存在直接返回，别瞎折腾
    if  {
      return GlobalDialog.instance;
    }
    this.visible = false;
    // 把当前正在创建的这个实例，挂到类本身身上
    GlobalDialog.instance = this;
  }
  open {
    this.visible = true;
    console.log;
  }
}
const d1 = new GlobalDialog;
const d2 = new GlobalDialog;
console.log; // true

这种写法在面试里特别受面试官待见。因为它kan起来结构完整，hen有“设计模式”的样子。它利用 `GlobalDialog.instance` 这个静态属性来充当守门员。不管你 `new` 多少次它dou只会给你吐出同一个对象。

但是说实话，在前端业务代码里这么写，有时候会觉得有点重。毕竟咱们写JShen多时候还是追求快和灵，为了一个单例搞个Class，还得记着静态属性，心智负担稍微大了一点点。

第五步：现代前端的真相——ES Module 也是单例？

聊到这里咱们得换个角度了。你有没有发现，现在hen多前端项目里大家好像根本不怎么写上面那些代码，但全局状态依然管得好好的？

秘密就在于 ES Module。

咱们先kan个例子，假设你有个配置文件：

// config.js
const appConfig = {
  apiUrl: 'https://api.my-awesome-app.com',
  timeout: 5000
};
export default appConfig;

然后在A文件里引用它，在B文件里也引用它：

// a.js
import config from './config.js';
console.log;
// b.js
import config from './config.js';
console.log;

你猜怎么着？`a.js` 里的 `config` 和 `b.js` 里的 `config`，是内存里的同一个对象！

这就是ES Module的特性：模块只加载一次后续导入的dou是同一个引用。这其实不就是天然的“单例模式”吗？而且还是“饿汉式”的。

所以hen多前端项目虽然嘴上没说“我在用单例模式”，但实际上早就用得飞起了。像什么全局的Store、全局的Router实例、全局的Axios封装，本质上dou是利用了模块的这种单例特性。这大概是Zui省心、Zui无感的实现方式了。

第六步：实战演练——Zuo一个全局的消息管理器

光说不练假把式。咱们来个稍微真实点的场景。假设你要给项目写一个全局的消息提示，比如右上角弹出的“保存成功”、“网络错误”这种小气泡。

Ru果每次调用 `Message.success` dou去 `document.body` 里 `appendChild` 一个新的DOM节点，那页面迟早会被撑爆，而且体验极差。正确的Zuo法是：维护一个队列，全局只有一个管理器在负责显示这些消息。

class MessageManager {
  constructor {
    if  {
      return MessageManager.instance;
    }
    this.queue = ;
    this.isShowing = false;
    MessageManager.instance = this;
  }
  show {
    this.queue.push;
    this.processQueue;
  }
  processQueue {
    if  return;
    this.isShowing = true;
    const text = this.queue.shift;
    // 模拟显示逻辑
    console.log;
    setTimeout => {
      this.isShowing = false;
      this.processQueue; // 递归处理下一个
    }, 2000);
  }
}
// 对外暴露一个简单的函数
let managerInstance = null;
export function showMessage {
  if  {
    managerInstance = new MessageManager;
  }
  managerInstance.show;
}

你kan，这样不管你在代码的哪个角落调用 `showMessage`，它们dou会乖乖地排好队，经由同一个管理器显示出来。这就是单例模式在UI层Zui经典的应用。

第七步：警惕陷阱——单例不是万Neng药

说了半天单例的好话，现在得泼盆冷水清醒一下。任何设计模式dou有它的适用场景，单例模式也不例外甚至Ke以说它是Zui容易被滥用的模式之一。

1. 全局状态的噩梦

单例本质上就是一个披着马甲的全局变量。一旦你把什么东西douZuo成单例，代码里的“隐形依赖”就会越来越多。A模块改了单例里的状态，B模块读出来傻眼了排查Bug的时候你会怀疑人生。这种“牵一发而动全身”的耦合，是维护性的大敌。

2. 测试的困难

写单元测试的时候，Zui怕的就是状态残留。Ru果你测试用例A修改了单例的内部数据，等你跑用例B的时候，单例里还残留着A的数据，结果就是测试时灵时不灵，让你抓狂。所以在测试环境下我们往往需要给单例加一个 `reset` 方法，手动清空状态，这又多了一层麻烦。

3. 并发的隐患

或者涉及到Worker线程时并发问题依然值得警惕。

什么时候该用它？

学了这么多，Zui后怎么判断该不该用单例呢？我给你一个特别实用的判断标准：

问自己两个问题：

这个对象在系统里是不是逻辑上就必须只有一份？

创建这个对象的成本是不是hen高，或者它需要维护一个贯穿生命周期的状态？

Ru果两个答案dou是Yes，那就大胆地用单例吧。Ru果只是图方便，想随便找个地方存数据，那还是三思而后行，别让全局变量把你的代码变成一团乱麻。

单例模式，说到底就是一种克制。它克制了创建对象的冲动，保证了系统的秩序。掌握了它，你的代码里就会少hen多莫名其妙的Bug，多一份井井有条的优雅。希望这篇渐进式的学习笔记，Neng让你对这个老生常谈的设计模式有新的认识。

---