先聊點實際的。觀察者模式大概是面試?yán)锍霈F(xiàn)頻率最高的設(shè)計模式之一但大多數(shù) C 開發(fā)者對它的理解還停留在“一個 Subject 維護 Observer 列表notify 的時候挨個調(diào) update()”這個課本版本上。這個版本本身沒錯可一旦你把它放進真實項目——尤其是網(wǎng)絡(luò)通信、 UI 事件分發(fā)、跨模塊狀態(tài)同步這類場景——你會立刻碰上一連串課本里沒有回答的問題觀察者生命周期和主題綁定太脆弱怎么辦通知順序能不能保證跨線程 notify 誰來管消息類型一多是不是要為每一種事件類型都建一套回調(diào)接口這篇文章不打算再復(fù)述一遍教科書例子。我想把我這幾輪項目里實際用過的幾種觀察者模式變體整理出來——包括解決懸垂指針的弱引用綁定、讓回調(diào)支持 lambda 的 function 聚合式觀察者、能扛跨線程的串行派發(fā)變體、以及批量聚合事件的性能優(yōu)化形態(tài)。每個變體我都盡量把設(shè)計動機、實現(xiàn)思路、以及它引入的新問題都講清楚。如果你是那種已經(jīng)會用標(biāo)準(zhǔn)模式、正在為工程里別扭之處頭疼的 C 開發(fā)者這篇文章應(yīng)該正好對胃口。1. 標(biāo)準(zhǔn)觀察者模式的固有毛病三個真實工程痛點在動手寫變體之前先把標(biāo)準(zhǔn)實現(xiàn)的“病根”分析清楚。我個人認(rèn)為觀察者模式本身沒有設(shè)計缺陷缺陷出在 C 這套語言特性加上真實工程環(huán)境之后使用者不得不面對的三個糾纏問題。第一個是生命周期問題。典型實現(xiàn)里Subject 持有的是 Observer 的原始指針或引用。一旦 Observer 對象被析構(gòu)但忘記從 Subject 的列表里移除自己那么下一次 Notify() 就是一次野指針調(diào)用程序大概率直接崩掉。你可能覺得“忘了解除訂閱”是粗心但真實項目里觀察者經(jīng)常分布在不同的模塊、由不同的 owner 管理析構(gòu)路徑極其復(fù)雜漏解綁幾乎是必然事件。我見過太多次因為這種問題線上崩潰的 case最后排查出來的原因根本不是業(yè)務(wù)邏輯而是某個模塊退出時沒有反注冊。第二個痛點是回調(diào)形態(tài)單一。標(biāo)準(zhǔn)模式要求 Observer 繼承一個帶 virtual Update() 的基類這就強加了繼承關(guān)系。但是很多場景下觀察者只是一個業(yè)務(wù)類它不想為了收個通知去繼承什么 ObserverBase又或者我們想讓某個普通成員函數(shù)、甚至 lambda 表達式成為觀察者標(biāo)準(zhǔn)模式完全沒法支持。這樣一來標(biāo)準(zhǔn)模式在 C 里顯得格外笨重——明明 std::function 已經(jīng)這么靈活了為什么觀察者還非得走虛函數(shù)那一套第三個痛點是上下文缺失。標(biāo)準(zhǔn)模式的 Notify() 不帶參數(shù)或者最多帶一個空泛的 Subject* 指針?？蓪嶋H的業(yè)務(wù)消息往往需要攜帶事件相關(guān)的上下文信息文件路徑、網(wǎng)絡(luò)包、進度百分比、狀態(tài)碼。為了解決這個問題常見的做法是給 Update() 塞一個 EventArg 基類指針然后在觀察者里向下轉(zhuǎn)型。這確實能用但每加一種事件類型就要新增一個 EventArg 子類觀察者內(nèi)部還要寫一堆 if-else 或 switch 處理不同消息時間一長代碼就變成了“類型分派地獄”。我列個表格總結(jié)一下標(biāo)準(zhǔn)模式的痛點后面所有變體都是圍繞這幾項在做文章痛點典型場景后果生命周期耦合模塊卸載時觀察者已析構(gòu)懸垂指針崩潰隨機出現(xiàn)回調(diào)形態(tài)僵化只想綁定一個現(xiàn)有成員函數(shù)被迫引入繼承關(guān)系或?qū)戇m配類消息上下文缺失需要傳遞進度值/錯誤碼/事件參數(shù)EventArg 子類爆炸類型分派混亂這三個問題如果只是出現(xiàn)在小 Demo 里確實無傷大雅可一旦觀察者模式接入到長周期運行的服務(wù)器進程或者大型客戶端軟件里它面對就不再是“好用不好用”而是“能不能繼續(xù)穩(wěn)定運行”。所以在實際工程里我更愿意把觀察者模式當(dāng)作一個“基座”在此基礎(chǔ)上按場景做調(diào)整變成不同的變體。2. 弱引用變體把裸指針換成 weak_ptr先解決崩潰問題解決生命周期問題最直接的辦法就是讓 Subject 持有 Observer 的弱引用而不是裸指針。這樣哪怕某個 Observer 已經(jīng)析構(gòu)它的 weak_ptr 會自動變成空懸狀態(tài)在通知階段做一個 lock() 判斷就能安全跳過。我把這種形態(tài)稱為“弱引用變體”。有人會說我在析構(gòu)函數(shù)里 unregister 不就行了這確實是標(biāo)準(zhǔn)做法但在項目里不太可靠。原因有兩個一是 Observer 可能根本不知道自己在哪個 Subject 上模塊間互相引用時很難保證反注冊調(diào)用一定發(fā)生在析構(gòu)之前二是就算你寫了 unregister也保不齊某個異步路徑在對象析構(gòu)之后還在觸達。用 weak_ptr 的方案就很省心。實現(xiàn)起來大概是這樣的思路讓觀察者本身繼承enable_shared_from_this在注冊的時候把自己的weak_ptr交出去Subject 內(nèi)部存儲std::liststd::weak_ptrIObserver。通知時先遍歷對每個 weak_ptr 執(zhí)行l(wèi)ock()如果成功說明對象還活著可以安全調(diào)用如果失敗就把這個空項從列表里剔除掉。class IObserver { public: virtual ~IObserver() default; virtual void Update() 0; }; class Subject { public: void Attach(const std::weak_ptrIObserver observer) { observers_.push_back(observer); } void Notify() { for (auto iter observers_.begin(); iter ! observers_.end();) { if (auto sp iter-lock()) { sp-Update(); iter; } else { iter observers_.erase(iter); } } } private: std::liststd::weak_ptrIObserver observers_; };這個寫法比裸指針安全得多但也有兩個新的實際問題需要處理。第一個是鎖的粒度lock()本身是有開銷的一次Notify()要調(diào)用 N 次鎖如果 Agent 特別多、通知又特別頻繁這個開銷會變得不可忽略后面我會在性能變體里再講怎么優(yōu)化。第二個是對象已被銷毀但仍排隊weak_ptr 能幫你擋住“已銷毀對象”但它無法阻止“還在活著但邏輯上已經(jīng)退出”的對象收到最后一輪通知。換句話說weak_ptr 解決的是內(nèi)存安全不解決業(yè)務(wù)邏輯上的生命周期語義。我在實際項目里還會配合做一個“代際令牌”的設(shè)計來彌補語義上的缺口。簡單說就是給每個觀察者注冊時分配一個單調(diào)遞增的令牌號注銷時把令牌號登記到 Subject 的失效集合里。通知時除了檢查 weak_ptr還檢查令牌是否在失效集合中。這樣既可以做到即時注銷生效也避免了“對象活著但業(yè)務(wù)已失效卻還在收通知”的尷尬。Subject::ObserverHandle Subject::Attach(const std::weak_ptrIObserver observer) { uint64_t token next_token_; observers_.push_back({token, observer}); return token; } void Subject::Detach(ObserverHandle handle) { invalid_tokens_.insert(handle); }這個代際令牌配合 weak_ptr 的方案我用了很久沒出過大問題。它唯一的代價是內(nèi)存里多了一個失效集合查詢是 O(1) 的通知時多一次哈希查找工程上完全可接受。如果你在維護一個生命周期特別復(fù)雜的系統(tǒng)——比如插件系統(tǒng)或者運行時熱加載系統(tǒng)這個變體幾乎是最穩(wěn)妥的起點。3. 回調(diào)聚合變體用 std::function 取代繼承體系第二個痛點回調(diào)形態(tài)僵化用弱引用變體解決不了。在標(biāo)準(zhǔn)模式里觀察者必須繼承抽象基類并實現(xiàn) Update()這等于強迫所有觀察者都進入同一個類型體系。更常見也更靈活的做法是不再定義 IObserver 接口而是直接把觀察者回調(diào)定義為std::function讓任何可調(diào)用對象都能成為觀察者。這個變體通常被稱為“事件聚合器”或“回調(diào)列表”。核心思路是用一個存儲回調(diào)函數(shù)對象的容器代替觀察者對象列表。實現(xiàn)上Subject 只需要暴露兩個接口一個注冊回調(diào)的Connect一個觸發(fā)回調(diào)的Notify。注冊回調(diào)時自定義一個Connection對象作為令牌用來管理解除訂閱避免直接用迭代器因為容器在并發(fā)或匿名回調(diào)場景下的迭代器很容易失效。class EventBus { public: using Callback std::functionvoid(const std::string, int); Connection Connect(Callback cb) { auto iter callbacks_.insert(callbacks_.end(), std::move(cb)); return Connection(this, iter); } void Notify(const std::string event, int value) { for (auto cb : callbacks_) { if (cb) { cb(event, value); } } } private: std::listCallback callbacks_; }; class Connection { public: Connection(EventBus* bus, std::listEventBus::Callback::iterator iter) : bus_(bus), iter_(iter) {} void Disconnect() { if (bus_) { bus_-callbacks_.erase(iter_); bus_ nullptr; } } private: EventBus* bus_; std::listEventBus::Callback::iterator iter_; };改成std::function聚合之后最大的好處是可以用 lambda 就地綁定一段邏輯或者綁定某個對象的成員函數(shù)完全不需要為了“收個通知”單獨建一個類。舉個具體的例子在某個消息處理模塊里我想訂閱一個“配置變更”事件只需要這樣configBus.Connect([this](const std::string key, int newValue) { reconfigureInternal(key, newValue); });如果用標(biāo)準(zhǔn)觀察者我得先定義一個ConfigObserver類繼承接口重寫 Update注冊到 Subject 里——代碼量差了一個數(shù)量級。這個變體也有坑而且還挺隱蔽。第一個坑是回調(diào)對象生命周期std::function能安全存儲 lambda但如果 lambda 捕獲了this指針那么 this 指向?qū)ο笪鰳?gòu)時回調(diào)里仍然持有一個懸垂 this。上一節(jié)的 weak_ptr 方案還只保護觀察者對象這一節(jié)直接掉進“捕獲了 this 卻沒人管”的陷阱。我用過一個非常穩(wěn)健的補充做法給Connect增加一個重載接受std::weak_ptrvoid作為哨兵在回調(diào)函數(shù)里先 lock 檢查如果失敗就跳過執(zhí)行Connection Connect(std::weak_ptrvoid guard, Callback cb) { auto wrapped [guard, cb std::move(cb)](auto... args) { if (auto locked guard.lock()) { std::invoke(cb, std::forwarddecltype(args)(args)...); } }; auto iter callbacks_.insert(callbacks_.end(), std::move(wrapped)); return Connection(this, iter); }本質(zhì)上是給 lambda 觀察者套了一層“守衛(wèi)”把生命周期安全延伸到回調(diào)捕獲的上下文對象上。第二個坑是通知順序的一致性。標(biāo)準(zhǔn)模式里你還能隱約感覺到 Observer 容器是 std::list追加順序就是通知順序但引入 lambda、匿名函數(shù)、自動斷開之后順序維護就沒有那么自然了。如果你有“先訂閱者先收到通知”這種業(yè)務(wù)訴求那你必須在文檔里明確這個語義并且堅決使用具有穩(wěn)定順序的容器?；卣{(diào)聚合變體是目前工程上最常用的形態(tài)官方事件框架、UI 框架幾乎全部采用這種設(shè)計。它犧牲了標(biāo)準(zhǔn)模式“代碼結(jié)構(gòu)一目了然”的優(yōu)勢但換來了極大的靈活性。如果你特別看重“觀察者必須是一個明確的類方便追蹤和測試”那標(biāo)準(zhǔn)模式可能更適合但如果你更看重擴展速度和組合能力回調(diào)聚合是更優(yōu)解。4. 線程安全變體串行派發(fā)與拷貝快照的取舍接下來的變體來自一個很具體的需求Subject 可能運行在后臺線程Observer 卻活在主線程或者一個事件可能要同時通知多個模塊而其中某個觀察者回調(diào)里居然會去修改 Subject 的觀察者列表。這種“通知過程中增刪觀察者”的情況恰恰是標(biāo)準(zhǔn)模式最容易出現(xiàn)隱蔽 bug 的角落。我遇到過的最典型的崩潰場景是這樣通知完第一個觀察者之后第二個觀察者的回調(diào)內(nèi)部觸發(fā)了解除訂閱把第三個觀察者從列表里移除了然后通知邏輯繼續(xù)遍歷用到了一個已經(jīng)失效的迭代器直接 UB。這類問題用簡單的互斥鎖能擋住一部分列表在遍歷中不被并發(fā)修改但擋不住“同一個線程里回調(diào)重入”造成的迭代器失效。因為你用 mutex 保護列表后回調(diào)里的 Detach 會去拿同一個鎖但這發(fā)生在觸發(fā)循環(huán)內(nèi)部會導(dǎo)致自死鎖如果不用鎖迭代器又會失效。我在工程里總結(jié)出三個靠譜的方案按場景選擇。方案一是串行派發(fā)隊列。這個思路是把真正的通知動作從 Notify 調(diào)用線程移到一個專門的事件循環(huán)里去執(zhí)行。所有收回調(diào)請求都入隊隊列背后有一個線程或者某個 strand逐個處理。這樣觀察者列表的遍歷只發(fā)生在隊列線程內(nèi)增刪也只在隊列線程內(nèi)完成天然沒有競爭。代價是通知變成異步的觀察者看到事件時事件已經(jīng)發(fā)生了有一會兒。這個方案特別適合 UI 框架里的界面刷新通知反正你也不想在后臺線程直接操 UI。方案二是拷貝快照派發(fā)。它的做法是在遞增互斥鎖的保護下把觀察者列表完整拷貝到一份臨時容器然后釋放鎖再遍歷臨時容器。這樣即使通知過程中有人修改了原列表也不會影響當(dāng)前這一輪派發(fā)迭代器安全也不會自死鎖。代價嘛自然是每次 Notify 都是一次 O(N) 的拷貝在觀察者數(shù)量很大、通知頻率又很高的情況下這個拷貝成本會讓人咂舌。void Notify(int eventId) { std::vectorCallback snapshot; { std::lock_guardstd::mutex lock(mutex_); snapshot callbacks_; // 拷貝 } for (auto cb : snapshot) { std::invoke(cb, eventId); } }方案三是倒序派發(fā) 延遲清理這是我自己常用的一個折中方案。倒序派發(fā)處理的是“回調(diào)里解除訂閱”的安全問題——因為從尾部向前遍歷時刪除當(dāng)前迭代器不會影響前面的迭代器但是如果刪除的是前面的觀察者問題依舊。所以我在實際里再疊加了一個“待刪除集合”回調(diào)里如果解除訂閱只是把對應(yīng)觀測者放進一個 pending 集合本輪 Notify 全部結(jié)束后再把 pending 集合里的節(jié)點統(tǒng)一從列表里摘除。這樣既不用在回調(diào)執(zhí)行時改鏈表結(jié)構(gòu)也避免拷貝快照的 O(N) 開銷。void Notify(int eventId) { // 遍歷正序但刪除動作不會立刻生效 for (auto iter callbacks_.begin(); iter ! callbacks_.end(); iter) { if (pending_removals_.contains(iter)) { continue; // 本輪仍然觸發(fā)? 這里看語義 } std::invoke(*iter, eventId); } // 統(tǒng)一清理 for (auto it : pending_removals_) { callbacks_.erase(it); } pending_removals_.clear(); }提醒一下這個延遲清理的語義值得認(rèn)真設(shè)計如果在第 3 個回調(diào)里解除了第 5 個觀察者那么這一輪該不該讓第 5 個觀察者繼續(xù)收到消息不同系統(tǒng)的預(yù)期不一樣。我傾向于“本輪不再觸發(fā)”——既然業(yè)務(wù)方已經(jīng)明確解除了訂閱就應(yīng)該立即生效但這會造成遍歷時跳過某些迭代器代碼里要小心維護。線程安全變體沒有一個通吃的銀彈。按我的經(jīng)驗事件頻率低、觀察者數(shù)量少的場景拷貝快照派發(fā)最省心事件頻率高、觀察者數(shù)量大但可以接受異步的場景串行派發(fā)隊列最穩(wěn)既不希望引入異步、又希望保持響應(yīng)速度的場景延遲清理配合一定的標(biāo)記位是值得深入的方向。5. 性能變體批量聚合事件與無鎖廣播說到性能就不得不面對觀察者模式的另一個尷尬現(xiàn)實它天生是一對多逐個調(diào)用而且調(diào)用的是 std::function 或虛函數(shù)本身就難以內(nèi)聯(lián)或向量化。觀察者很多、事件很密集時模式本身的開銷會成為瓶頸。我實際遇到過一個場景游戲引擎里每幀要廣播位置變更事件場景內(nèi)有幾百個實體訂閱了這個事件每個實體收到之后都去做各自的碰撞檢測或者渲染更新。最初的實現(xiàn)就是普通的事件總線結(jié)果 Profiling 顯示 Notify 階段占了每幀 CPU 時間的 15% 以上。這不是業(yè)務(wù)邏輯慢純粹是模式開銷。解決這個問題的思路有兩個方向。第一個方向是批量聚合事件不要把每個微小變化立刻作為單獨事件廣播而是把一段時間內(nèi)或一幀內(nèi)的同類事件合并成一個批處理事件在幀末統(tǒng)一派發(fā)。比如位置變更可以先寫到一個待發(fā)數(shù)組里一幀結(jié)束時合并成“場景內(nèi)所有實體位置快照”一次性廣播。觀察者從“被調(diào)用 N 次”變成“被調(diào)用一次收一個數(shù)組”。這個變體犧牲了實時性但換來了巨大的派發(fā)開銷下降。第二個方向是無鎖或有鎖但極少沖突的廣播。如果觀察者列表在運行期間只會在初始化階段固定好運行階段不再增刪那么你就可以用一個固定大小的std::array或std::vectorCallback通知時直接遍歷不加鎖。因為“沒有并發(fā)增刪”這個前提意味著迭代一致性天然成立。我在實踐中把這種前提明確寫進接口文檔運行期禁止 Connect/Disconnect必須先在 setup 階段注冊完畢。這聽起來限制很大但在很多系統(tǒng)里完全成立比如網(wǎng)絡(luò)包處理管線包處理階段絕不允許動態(tài)調(diào)整處理函數(shù)。還有一個更底層的性能技巧空間局部性。標(biāo)準(zhǔn)std::listCallback的節(jié)點散落在內(nèi)存各處遍歷時會有嚴(yán)重的 Cache Miss。換成std::vectorCallback之后回調(diào)地址是連續(xù)內(nèi)存遍歷速度通常能提高 30%50%。代價是 vector 的插入會移動元素迭代器穩(wěn)定性差但如果你能接受“觀察者數(shù)量不大、增刪不頻繁”vector 是明顯更優(yōu)的選擇。class BroadcastBus { public: void Setup(std::vectorCallback cbs) { callbacks_ std::move(cbs); // 固定 } void Notify(const FrameUpdate frame) { for (const auto cb : callbacks_) { // 連續(xù)內(nèi)存cache友好 cb(frame); } } private: std::vectorCallback callbacks_; };不過要注意性能優(yōu)化做到這一步觀察者模式的“動態(tài)靈活性”已經(jīng)被削弱了不少。我發(fā)現(xiàn)很多人在做性能優(yōu)化時容易上頭最后把模式改得已經(jīng)看不出觀察者模式的樣子了。我的建議是分階段先用 Profiling 確認(rèn)這個版本真是瓶頸再考慮性能變體如果只是懷疑“它可能慢”我寧愿先保持代碼清晰等其他優(yōu)化手段用完再看它。6. 語言特性加成變參模板和運行時概念約束的變體形態(tài)再往前走一步C 的語言特性還能讓觀察者模式長出一些更現(xiàn)代、更靈活的形態(tài)。我提三種我覺得實踐中最有價值的變參模板泛型化、概念約束、以及泛型事件令牌。第一種是變參模板泛型化。標(biāo)準(zhǔn)模式和回調(diào)聚合都有一個預(yù)設(shè)約定事件攜帶的參數(shù)表是固定的最多兩個、三個參數(shù)。而真實系統(tǒng)里不同事件的參數(shù)簽名完全不同有的要傳三個參數(shù)有的一個都不傳。變參模板可以讓我們把事件類型本身參數(shù)化真正做到“一個總線任意簽名”。templatetypename... Args class EventChannel { public: using Callback std::functionvoid(Args...); void Publish(Args... args) { for (auto cb : callbacks_) { cb(args...); } } private: std::vectorCallback callbacks_; }; // 用法 EventChannelint, std::string config_changed; EventChannel tick_channel;好處一眼就能看出來不同事件擁有不同簽名不再需要把所有東西都塞進一個 EventArg 基類也不用做向下轉(zhuǎn)型。發(fā)布和訂閱的類型安全是由編譯器保證的傳錯參數(shù)類型在編譯期就報錯。缺點是實現(xiàn)分布式的事件路由時所有不同簽名的通道各自獨立要統(tǒng)一管理就很麻煩通常建議用一個上層管理器把這些通道實例都聚合起來統(tǒng)一注冊。第二種是概念約束。這是 C20 以后的新能力我們可以給觀察者回調(diào)定義一些語義約束比如“必須是可以無異常調(diào)用的”。配合std::is_nothrow_invocable_v這類 type trait可以靜態(tài)斷言回調(diào)不會拋出未捕獲異常。因為觀察者模式在廣播場景下某個觀察者拋異常會導(dǎo)致后續(xù)所有觀察者收不到消息。我建議把回調(diào)標(biāo)記為noexcept或者在派發(fā)層捕獲所有異常保證一個觀察者的失敗不拖垮整個廣播鏈路。templatetypename F concept NoThrowObserver std::is_nothrow_invocable_vF, int; templateNoThrowObserver... Observers void Broadcast(int value, Observers... obs) { (obs(value), ...); // 折疊表達式逐個安全調(diào)用 }第三種是泛型事件令牌。我們可以用一個枚舉、一個字符串 ID 或者一個類型標(biāo)簽作為事件的唯一“鑰匙”將不同類型的事件映射到不同通道或者同一通道的不同回調(diào)上。我在項目里見過一個優(yōu)雅的實現(xiàn)以事件類型比如struct FileOpenedEvent這種 tag作為模板參數(shù)用std::type_index作為事件的 key訂閱者注冊type_index - EventChannelEventData的映射。templatetypename EventData class EventBus { public: templatetypename Observer void AddObserver(Observer obs) { callbacks_.push_back(std::forwardObserver(obs)); } templatetypename... Args void Publish(Args... args) { EventData event{std::forwardArgs(args)...}; for (auto cb : callbacks_) { cb(event); } } private: std::vectorstd::functionvoid(const EventData) callbacks_; };這種泛型事件形態(tài)的最大優(yōu)點是類型安全發(fā)布者與訂閱者通過同一個 EventData 類型達成契約任何一段代碼要想知道某一類事件長什么樣看一個 struct 定義就夠了。它在需要高可維護性的中大型項目里非常好用能有效抑制“魔法數(shù)字”“魔法字符串”散布在代碼里。模板與約束為觀察者模式帶來的還不只是效率與類型安全它本質(zhì)上是把“消息協(xié)議”從運行期約定推到了編譯期校驗。但代價也突出模板代碼調(diào)試難度高錯誤信息晦澀。如果你或者你的團隊成員模板功底不深我建議先從簡單的回調(diào)聚合變體起步等確實碰到類型不安全問題時再泛化。7. 寫在最后的變體選擇建議寫了這么多到底該怎么選我個人的習(xí)慣是畫一張表先看業(yè)務(wù)約束再定方案。如果你正在設(shè)計一個新的觀察者機制可以參考這個決策路徑約束條件推薦變體理由觀察者生命周期不明確弱引用變體 代際令牌防懸垂防業(yè)務(wù)語義誤觸觀察者回調(diào)形態(tài)多樣、希望免繼承回調(diào)聚合變體std::function 靈活、輕量跨線程廣播串行派發(fā)隊列 / 拷貝快照派發(fā)兼顧安全與實時性高頻通知、海量觀察者批量聚合事件 vector 固定列表cache 友好、派發(fā)次數(shù)驟降事件類型多、契約要求強變參模板泛型通道編譯器保證類型契約如果讓我只選一個“萬金油”組合我會首選弱引用哨兵 std::function 回調(diào)聚合 延遲清理 串行派發(fā)選項。它能覆蓋絕大多數(shù)工程場景而且每一層都可以按需裁剪。要知道觀察者模式的變體設(shè)計不是越花哨越好。多數(shù)時候標(biāo)準(zhǔn)模式 少量保護性修改已經(jīng)能活得很好真正驅(qū)動變體出現(xiàn)的是真實工程里“生命周期安全、跨線程通知、類型靈活、性能可控”這四個維度中的至少一個被壓到臨界點。建議你在動手改造之前先拿 Profiling 數(shù)據(jù)和線上崩潰日志說話讓需求驅(qū)動設(shè)計而不是為了炫技去堆砌變體。