GetX

一個「切換帳號」引爆四個 Bug 子母帳號功能很直覺：母帳號可以切換到子帳號視角，查看子帳號的健康日記、操作資料。技術上就是換一組 JWT，重新載入資料。 聽起來簡單，實際上踩了四個 GetX 狀態管理的地雷，每個都不是表面看得出來的問題。 Bug 連鎖反應全景圖 先看整體：四個 bug 環環相扣，每修一個就暴露下一個。 flowchart TD A[切換子帳號] --> B{JWT 更新了？} B -->|是| C{userId / documentId 更新了？} C -->|否| D[API 500 / 日記查錯帳號] C -->|修好| E{ViewModel 有重建？} E -->|刪除重建| F{UI widget 指向新 ViewModel？} F -->|否：持有舊參考| G[首頁資料不更新] F -->|改為原地刷新| H{全域變數也更新了？} H -->|否：top-level final| I[Dialog 功能全失效] H -->|改為 getter| J{App 重啟能恢復？} J -->|否：狀態在記憶體| K[母帳號控制權消失] J -->|持久化到 SharedPreferences| L[全部修好] classDef error fill:#f8d7da,stroke:#dc3545,color:#721c24 classDef success fill:#d4edda,stroke:#28a745,color:#155724 classDef warning fill:#fff3cd,stroke:#ffc107,color:#856404 class D,G,I,K error class L success class A,B,C,E,F,H,J warning 第一坑：JWT 換了，身份沒換 切換帳號的核心邏輯只做了一件事——替換 JWT： ...

前言：Flutter 狀態管理的核心挑戰 在 Flutter 開發中，狀態管理是最重要也最複雜的主題之一。當應用程式規模增長，Widget 樹層級加深，如何讓不同層級的 Widget 能夠正確地監聽和響應狀態變化，成為每個 Flutter 開發者必須面對的挑戰。 選擇錯誤的狀態監聽方式，會導致： ❌ 不必要的重繪：整個 Widget 樹被重建，效能下降 ❌ 記憶體洩漏：忘記釋放監聽器，導致記憶體持續增長 ❌ 狀態不同步：多個 Widget 顯示不一致的資料 ❌ 程式碼難以維護：狀態邏輯散落各處，難以追蹤 本文涵蓋內容 本文將深入探討 Flutter 四大主流狀態管理方案的監聽機制： Provider：Flutter 官方推薦的輕量級狀態管理 Bloc：基於 Stream 的企業級狀態管理 Riverpod：Provider 的改進版本，解決了 Provider 的核心問題 GetX：高效能的響應式狀態管理 我們將從實際問題出發，比較這四種方案的： 🔍 核心原理：底層如何實現狀態監聽 💻 實戰範例：可執行的完整程式碼 ⚡ 效能表現：重繪範圍、記憶體使用 🎯 適用場景：什麼情況下使用哪種方案 ⚠️ 常見陷阱：實戰中容易踩的坑 Provider 狀態監聽機制 Provider 是 Flutter 官方推薦的狀態管理方案，基於 InheritedWidget 實現。它的核心優勢是簡單易用，適合中小型應用。 Provider 核心概念 Provider 使用 依賴注入 (Dependency Injection) 和 作用域 (Scope) 的概念來管理狀態： flowchart TB App[MyApp] --> P1[ChangeNotifierProvider] P1 --> Scope1[作用域 1] Scope1 --> Route1[Route 1] Scope1 --> Route2[Route 2] Route1 --> W1[Widget A<br/>context.watch] Route1 --> W2[Widget B<br/>context.read] Route2 --> W3[Widget C<br/>❌ 無法存取] P1 -.->|提供狀態| W1 P1 -.->|提供狀態| W2 style P1 fill:#4ade80,color:#000 style W1 fill:#60a5fa,color:#000 style W2 fill:#60a5fa,color:#000 style W3 fill:#ef4444,color:#fff 關鍵概念： ...