昨天我們把代購 App 的靜態資料結構定案——買家、商品、訂單這些實體怎麼互相關聯，也知道哪張表該有哪些欄位。但資料表只回答了「東西存在哪裡」，沒有回答「畫面現在應該長什麼樣子」。設計師常畫出精美的靜態頁面，但實際開發時，使用者點擊按鈕、網路延遲、資料載入失敗，都會讓同一個畫面長出完全不同的樣貌。如果沒有一套嚴謹的規則定義這些狀態之間怎麼切換，系統很容易出現「狀態爆炸」——狀態數量隨功能增加而失控成長，讓人再也講不清楚畫面現在到底處於哪一種情況。這時候，有限狀態機（FSM）的概念，就是把混沌的互動邏輯，轉化成可預測的工程規範。

一、UI 狀態遷移 UI State Transitions

定義：指 UI 在不同情境下所呈現的具體視覺與功能樣態，以及這些樣態之間如何切換的規則。

目的：確保使用者在與系統互動時，介面始終處於「已知」且「合乎預期」的狀態，避免出現像是「Loading 畫面卡住且無法取消」這種異常情境。

常見的 UI 狀態：

• Idle（閒置／初始）：系統等待使用者操作。
• Loading（載入中）：系統處理請求中，通常配合 Disable 按鈕或 Skeleton Screen。
• Success（成功）：資料獲取完成，渲染內容。
• Error（錯誤）：發生連線逾時或後端報錯，顯示錯誤提示與重試機制。
• Empty（空狀態）：資料為空時的友善引導。

二、有限狀態機 Finite State Machine, FSM

定義：一種數學模型，用來描述系統在任何給定時間點下，只能處於有限數量中的其中一種狀態，並且只能透過特定的事件（Event）觸發狀態的轉移（Transition）。

關鍵組成：

• States（狀態）：系統當前所處的情況，例如 Idle、Loading、Success。
• Events（事件）：導致狀態轉換的觸發因子，例如使用者點擊「送出」、API 回傳 200。
• Transitions（轉換）：從一個狀態到另一個狀態的明確路徑。
• Guards（守衛條件）：決定轉換是否發生的附加條件，例如只有欄位不為空時，才允許進入 Loading 狀態。

三、代購 App 實例：買家登入流程

以代購 App 的登入功能為例，用 FSM 的邏輯規劃一次：

1. 初始狀態 Idle：買家輸入帳號密碼，送出按鈕為可點擊。
2. 事件觸發：買家點擊「登入」。
3. 轉換：系統從「Idle」轉為「Loading」。
4. 狀態行為：「Loading」期間，送出按鈕變為不可點擊，畫面出現 Spinner。
5. 事件處理：API 回傳結果後，依回傳碼走向不同狀態——
   • 若回傳 200：轉換至「Success」，跳轉至首頁。
   • 若回傳 401：轉換至「Error」，顯示「密碼錯誤」訊息；買家重新輸入密碼這個新事件，才會把狀態帶回「Idle」。

把「Error」跟「回到 Idle」分成兩個獨立的轉換，而不是同一步驟一次做完，是這裡的關鍵：FSM 每一次轉換只能對應一個明確的事件跟一個明確的目的狀態，不能「同時」發生兩件事。

四、結論

學習 UI 狀態遷移與 FSM 之後，我意識到過去自己在規劃系統邏輯時，常常只想著 Happy Path，忽略了「當事情不如預期時，系統該怎麼走」。FSM 強迫我們窮舉所有狀態與轉換路徑，這不只讓開發與測試更有明確依據，也讓使用者體驗更一致。把這種思維放進代購 App 的登入、送出委託等每一個互動裡，系統的邏輯會更健壯，也更容易維護。一開始不知道「狀態爆炸」這個概念時，遇到畫面表現異常，我只能籠統地說「發生錯誤」，完全講不出是哪個環節出了問題，更別提要從哪裡下手修，只能用這種很大範圍的話一言以蔽之。學了 FSM 之後，我才有辦法把「發生錯誤」拆解成具體的狀態跟轉換——是哪個事件沒有對應到正確的狀態、還是哪條轉換路徑根本沒被定義到，才終於有語言可以精準描述問題出在哪裡。