Flutter

前言：當 Banner 在眾目睽睽下消失 如果你曾經盯著一個「昨天還好好的」功能，然後花了幾小時才發現問題根本不在你想的地方——恭喜你，你已經正式成為資深工程師了。 這次的主角是一個 Flutter App 的首頁輪播 Banner。用戶回報說「Banner 不見了」，而我的第一反應是：「一定是最近的 commit 搞壞的！」 （劇透：不是。） 第一階段：追蹤嫌疑犯 嫌疑人一號：最近的 Git Commit 最近剛好有一個 commit 修改了後端的 middleware，用來處理認證相關的端點。自然而然，我先從這裡開始查： git show abc123 # fix: add middleware to strip auth header for public endpoints 看起來這個 middleware 只處理 /api/auth/forgot-password 這類認證端點，跟 Banner API 完全無關。 結論：無罪釋放。 嫌疑人二號：Strapi 權限設定 接下來檢查 Strapi Admin 的權限設定。Public 角色的 app-home-page 權限： 角色 find 權限 Authenticated ✅ 已開啟 Public ✅ 已開啟 權限設定完全正確。 結論：也不是兇手。 第二階段：真相大白 測試 REST API 直接用 curl 測試 REST API： ...

前言：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) 的概念來管理狀態： 關鍵概念： Provider 有作用域限制：只有在 Provider 子樹內的 Widget 能存取狀態 三種存取方式：context.watch()、context.read()、context.select() 自動重繪機制：使用 watch 時，狀態改變會自動觸發 Widget 重繪 實戰問題：跨路由讀取 Provider 這是我在開發中遇到的真實問題： ...