北京
上一篇講原子事務時，我們聊了狀態一致性如何保證。這次往下挖一層，看看調度器（Scheduler）是怎么設計的。不同的調度策略各有什么取舍，以及我們的實現怎么對應到那張調度流程圖里的路徑。
調度器是響應式系統里的"隱形指揮官"。
它不負責決定"要不要算"，只負責決定"什么時候算"。
調度策略大致分幾類。按優先級排序是其中一種：好處是能防止低價值更新卡住高優先級交互；壞處是實現復雜得多，系統得同時追蹤截止時間和優先級。這個差異會影響整個系統的策略走向。
從數據更新到UI更新，不同框架在調度器設計上做了不同取舍。這些取舍直接影響性能優化方向和開發者的心智模型。
原子事務那章有三個關鍵場景。事務中讀取值有兩種做法。之前我保留了原始的transaction()實現，方便跟早期例子對比。但實際用起來，transaction()的邏輯應該被atomic()取代。
從代碼角度看，具備完整事務語義的是atomic()。現在的transaction()只相當于批量操作，缺了回滾能力，語義跟上一篇說的不完全對得上。
代碼里把transaction()直接代理給了atomic()，簽名保持兼容同步和異步兩種情況。這樣對外接口沒變，內部實現換成了語義更完整的版本。
給scheduleJob()加了muted檢查，防止回滾期間塞進新任務。如果job已銷毀、或者處于muted狀態，直接返回不加入隊列。其他邏輯不動，只是讓實現行為和上面說的調度策略保持一致。
有個有意思的問題：開發者需要知道調度器存在嗎？
React里開發者經常得考慮"狀態更新不會立即生效"，所以心智模型必須包含批量化的概念。Solid或者基于Signals的系統里，計算……
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
