效能考量

最小化重建

builder 只會在讀取到的 ref 或 computed 變化時重新執行。
搭配 ComputedBuilder 或拆成小部件，可進一步縮小重建範圍。

效能優化實作

所有響應式 widgets（ComputedBuilder、CompositionWidget、CompositionBuilder）都採用了優化的重建機制：

ComputedBuilder 優化：

使用自訂 Element 實作，提供最佳效能：

更低延遲：單次更新延遲降低 15-25%（針對簡單 widgets）
更少記憶體：每個實例減少約 56 bytes（~15%）
直接重建：使用 markNeedsBuild() 而非 setState()，避免 microtask 調度開銷
可預測批次處理：同步更新的批次行為更一致

技術細節：

移除 scheduleMicrotask 開銷（每次更新節省 ~200-500 CPU cycles）
移除 setState 閉包創建（節省 ~30 CPU cycles）
無需 State 物件，減少記憶體佔用和 GC 壓力

CompositionWidget 和 CompositionBuilder 優化：

使用直接 markNeedsBuild() 調用取代 setState()：

降低開銷：每次響應式更新節省 ~50 CPU cycles
更快響應：無需創建 setState 閉包（節省 ~30 cycles）
減少檢查：避免 setState 的 debug assertions（節省 ~15 cycles）
整體提升：響應式更新性能提升 5-10%

所有優化都保持 API 向後兼容，無需修改現有代碼。

批次更新

多次 .value = ... 操作會在同一個 microtask 中批次觸發，避免重複 rebuild。
若需要立即看到中間狀態，可使用 await Future.microtask((){}) 強制切割更新。

建議實務

用 computed 快取昂貴的計算，例如排序、過濾或統計。
在 builder 中只讀取必要的 ref，其餘資料可透過 const widget 或拆成子 widget。
利用 provide / inject 傳遞 Ref，而非直接傳遞大型物件，可確保真正使用者才會重建。

監控與除錯

使用 watchEffect 臨時觀察依賴，搭配 debugPrint 確認哪些值觸發更新。
若遇到 Hot Reload 後狀態錯亂，檢查 ref 宣告順序是否被改動。

延伸閱讀