從一個(gè)小事故說起不知道你有沒有遇到過這樣的場(chǎng)景用戶瘋狂點(diǎn)擊打開新網(wǎng)頁(yè)按鈕結(jié)果屏幕上彈出了十幾個(gè)一模一樣的窗口。又或者你在項(xiàng)目里維護(hù)一個(gè)全局配置對(duì)象結(jié)果發(fā)現(xiàn)每個(gè)模塊都new了一個(gè)新實(shí)例改了這個(gè)沒改那個(gè)最后狀態(tài)亂七八糟。這些問題背后其實(shí)指向同一個(gè)根源有些東西整個(gè)系統(tǒng)只需要一個(gè)。這就是我們今天要聊的單例模式Singleton Pattern。單例模式到底是什么先給個(gè)定義確保一個(gè)類只有一個(gè)實(shí)例并提供一個(gè)全局訪問點(diǎn)。說白了就是這個(gè)類你new一百次拿到手的還是同一個(gè)對(duì)象。它解決的是全局唯一的問題——全局狀態(tài)管理、資源復(fù)用、配置統(tǒng)一都離不開它。單例模式屬于 GoF 23 種設(shè)計(jì)模式中的創(chuàng)建型模式跟工廠模式、建造者模式是鄰居。但它的特殊之處在于別的創(chuàng)建型模式關(guān)心的是怎么創(chuàng)建它關(guān)心的是怎么不創(chuàng)建多個(gè)。單例模式的本質(zhì)不是只能創(chuàng)建一個(gè)實(shí)例而是提供一個(gè)全局訪問點(diǎn)且這個(gè)訪問點(diǎn)背后永遠(yuǎn)只有一個(gè)實(shí)例。從一個(gè)彈窗管理器開始先看一個(gè)最經(jīng)典的場(chǎng)景頁(yè)面上有個(gè)按鈕點(diǎn)擊打開一個(gè)新窗口。我們當(dāng)然不希望每次點(diǎn)擊都window.open一發(fā)不可收拾而是希望有一個(gè)統(tǒng)一的彈窗管家來管理這個(gè)行為。!DOCTYPE html html langen head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title單例模式打開窗口/title /head body button idopenBtn打開新網(wǎng)頁(yè)/button script class Popup { static ins; // 靜態(tài)屬性存放單例實(shí)例 static getInstance() { if (!Popup.ins) { Popup.ins new Popup(); } return Popup.ins; } open(url) { window.open(url, _blank); } } const a Popup.getInstance(); // 單例方式獲取實(shí)例替代 new const b Popup.getInstance(); console.log(a b); // true證明是同一個(gè)實(shí)例 const openBtn document.getElementById(openBtn); openBtn.addEventListener(click, () { a.open(https://www.baidu.com); }); /script /body /html這段代碼的核心邏輯其實(shí)就三行static getInstance() { if (!Popup.ins) { Popup.ins new Popup(); } return Popup.ins; }你會(huì)發(fā)現(xiàn)這就是一個(gè)惰性初始化Lazy Initialization第一次調(diào)用getInstance()時(shí)才創(chuàng)建實(shí)例之后直接返回緩存的那個(gè)。用a b驗(yàn)證一下確實(shí)是同一個(gè)對(duì)象。但問題來了這個(gè)實(shí)現(xiàn)有個(gè)明顯的漏洞——Popup.ins是公開的誰(shuí)都可以直接改Popup.ins null; // 手賤一下單例就沒了 Popup.ins new Popup(); // 或者直接給你換個(gè)新的對(duì)于中級(jí)開發(fā)者來說我們得把單例這件事做得更可靠一些。更可靠的單例實(shí)現(xiàn)方案一閉包 IIFEconst Popup (function () { let instance; // 私有變量外部無(wú)法直接訪問 class PopupClass { open(url) { window.open(url, _blank); } } return { getInstance() { if (!instance) { instance new PopupClass(); } return instance; } }; })(); const a Popup.getInstance(); const b Popup.getInstance(); console.log(a b); // true這樣instance被閉包保護(hù)起來外部根本摸不到單例的唯一性就有了保障。方案二ES6 模塊天然單例在 ES6 模塊體系中模塊本身就是單例的——無(wú)論被多少地方import模塊代碼只執(zhí)行一次導(dǎo)出的對(duì)象永遠(yuǎn)是同一個(gè)。// popup.js class Popup { open(url) { window.open(url, _blank); } } export const popupInstance new Popup();// 任何地方使用 import { popupInstance } from ./popup.js; popupInstance.open(https://www.baidu.com);這種方式簡(jiǎn)單粗暴也是前端工程化中最常用的單例實(shí)現(xiàn)方式。你項(xiàng)目里的 Axios 實(shí)例、WebSocket 連接、Vuex/Pinia Store本質(zhì)上都是這么玩的。方案三Symbol 做私有 key如果你想繼續(xù)用 Class 的寫法但又想保護(hù)ins不被隨意訪問可以用 Symbolconst INS Symbol(singleton); class Popup { static getInstance() { if (!Popup[INS]) { Popup[INS] new Popup(); } return Popup[INS]; } open(url) { window.open(url, _blank); } }Symbol作為屬性 key 不會(huì)被常規(guī)遍歷發(fā)現(xiàn)也不會(huì)跟其他屬性沖突。不過說實(shí)話在 JS 里防君子不防小人真要改還是能通過Object.getOwnPropertySymbols拿到。所以工程實(shí)踐中方案二ES6 模塊才是最主流的選擇。單例模式在前端的高頻落地場(chǎng)景理論講完了來看看真實(shí)項(xiàng)目中單例模式都在哪里打工。場(chǎng)景一全局狀態(tài)管理Pinia / Vuex你用 Pinia 定義的 Store本質(zhì)上就是一個(gè)單例。不管在哪個(gè)組件里調(diào)用useUserStore()拿到的都是同一個(gè)實(shí)例狀態(tài)自然就同步了。// stores/user.js import { defineStore } from pinia; export const useUserStore defineStore(user, { state: () ({ name: , token: }), actions: { setUser(user) { this.name user.name; this.token user.token; } } });Pinia 內(nèi)部保證了同一個(gè) id 的 Store 只會(huì)被創(chuàng)建一次——這就是單例模式在框架層面的應(yīng)用。場(chǎng)景二Axios 實(shí)例封裝幾乎每個(gè)前端項(xiàng)目都會(huì)封裝一個(gè)統(tǒng)一的 HTTP 客戶端// utils/request.js import axios from axios; const request axios.create({ baseURL: /api, timeout: 10000, }); // 請(qǐng)求攔截器 request.interceptors.request.use(config { config.headers.Authorization localStorage.getItem(token) || ; return config; }); export default request;整個(gè)項(xiàng)目共享這一個(gè) Axios 實(shí)例好處顯而易見攔截器配置一次、Token 注入一處、錯(cuò)誤處理統(tǒng)一。如果每個(gè)模塊都自己axios.create一個(gè)那你改攔截器就要改到懷疑人生。場(chǎng)景三WebSocket 連接管理一個(gè)頁(yè)面通常只需要一條 WebSocket 連接。如果每次組件掛載都new WebSocket()服務(wù)端可能會(huì)因?yàn)檫B接數(shù)爆掉而把你拉黑。// utils/socket.js class SocketManager { static instance null; static getInstance() { if (!SocketManager.instance) { SocketManager.instance new SocketManager(); } return SocketManager.instance; } connect(url) { if (this.ws this.ws.readyState WebSocket.OPEN) { return this.ws; // 已連接直接復(fù)用 } this.ws new WebSocket(url); return this.ws; } } export default SocketManager;單例模式的陰暗面聊完了好處也得說實(shí)話。單例模式在江湖上有個(gè)外號(hào)叫披著設(shè)計(jì)模式外衣的全局變量它確實(shí)有一些需要警惕的地方。問題一隱藏的耦合單例是全局可訪問的這意味著任何模塊都可以依賴它。如果濫用你的代碼會(huì)變成一張誰(shuí)也理不清的依賴網(wǎng)。問題二難以測(cè)試因?yàn)閱卫侨治ㄒ坏脑趩卧獪y(cè)試中很難重置它的狀態(tài)。你測(cè)完一個(gè)用例單例的臟數(shù)據(jù)可能影響下一個(gè)用例。問題三違反單一職責(zé)原則單例類往往既要管自己的業(yè)務(wù)邏輯又要管自己只能有一個(gè)實(shí)例這件事。這在大型項(xiàng)目中會(huì)讓類的職責(zé)變重。設(shè)計(jì)模式不是銀彈單例用好了是全局狀態(tài)管理利器用不好就是隱藏的全局變量災(zāi)難。什么時(shí)候該用單例給你一個(gè)簡(jiǎn)單的判斷標(biāo)準(zhǔn)? 資源本身在業(yè)務(wù)上就是唯一的如全局配置、日志收集器、數(shù)據(jù)庫(kù)連接池、WebSocket 連接? 創(chuàng)建成本高且可以復(fù)用如線程池在 JS 中更多是連接池、緩存管理器? 僅僅因?yàn)榉奖憔桶哑胀▽?duì)象改成單例比如用戶信息、購(gòu)物車數(shù)據(jù)這些應(yīng)該交給狀態(tài)管理工具Pinia/Vuex/Redux而不是手動(dòng)實(shí)現(xiàn)單例總結(jié)這篇文章從一個(gè)彈窗管理的例子出發(fā)聊了單例模式的核心思想、多種實(shí)現(xiàn)方式以及在前端工程中的真實(shí)應(yīng)用場(chǎng)景。來一張圖幫你快速回顧實(shí)現(xiàn)方式適用場(chǎng)景私有性Class 靜態(tài)方法簡(jiǎn)單場(chǎng)景、教學(xué)演示? 屬性公開閉包 IIFE需要保護(hù)實(shí)例引用? 私有變量ES6 模塊導(dǎo)出實(shí)例工程實(shí)踐首選? 天然單例Symbol 屬性需要 Class 寫法 一定保護(hù)?? 半私有核心就一句話確保一個(gè)類只有一個(gè)實(shí)例并提供一個(gè)全局訪問點(diǎn)。下次當(dāng)你發(fā)現(xiàn)某個(gè)對(duì)象整個(gè)項(xiàng)目只需要一個(gè)的時(shí)候別猶豫單例模式安排上。但也要記得模式是工具不是信仰——適合的才是最好的。