結果連假出去玩一個太開心，忘記有鐵人賽這件事情了
不過沒關係，還是會持續寫完整。這邊也祝讀者們中秋節快樂！！

先記住：用合法狀態與事件取代互相矛盾的布林值。
需要深入時：再使用狀態機工具。

四個布林值，長出十六種組合

表單裡有 isLoading、isSuccess、hasError、isEditing。
功能越加越多，有一天畫面同時顯示成功和錯誤，但是按鈕還在轉圈。

四個布林值有十六種組合，但產品通常不需要這麼多合法狀態。
互相矛盾的狀態會讓同步更困難，可以合併成明確的 status。

狀態機其實是在畫允許的路

有限狀態機的核心是：
目前在哪個狀態、收到什麼事件、允許走到哪裡。對優惠表單，
可以先有 editing、validating、ready、invalid、unknown。

在 editing 收到 submit，通過基本格式檢查後才進入 validating。
收到成功回應，且它對應目前購物車版本，才能進入 ready。
若回應明確說券不適用，進入 invalid；若逾時而無法確定，進入 unknown。
修改商品則讓已確認報價失效，回到需要驗證的狀態。

這些轉移條件，也就是 guard，直接表達產品規則。

不只列狀態，還要列副作用

送請求、記錄分析事件、導頁都是副作用，不能只靠「狀態變了」就隨意重複執行。
應說清楚哪個事件觸發、是否能重複，以及如何清理。

例如 validating 收到第二次 submit，可以忽略或替換，取決於產品需求。
不能讓 AI 自己選。離開頁面後要取消不再需要的工作，且避免把回應寫入已失效的流程。

也別把所有獨立事情擠進同一個巨型狀態。
優惠驗證與地址編輯可能同時進行，硬列成每一種組合會爆炸。
先依責任分開，再定義結帳時需要滿足的共同條件。

一張小表就能開始

• editing + submit → validating；前提是輸入格式可接受。
• validating + validResponse → ready；前提是版本仍相同。
• validating + businessRejection → invalid；保留輸入。
• validating + timeout → unknown；提供重新確認路徑。
• ready + cartChanged → editing；清除報價有效性。
• 任意狀態 + staleResponse → 原狀態；忽略過期結果。

小功能可以用清楚的條件或 reducer 實作，不一定需要狀態機函式庫。
工具是實作選擇，轉移規則才是分析成果。

可以交給 AI 的 Prompt

請依上述優惠表單狀態與事件，實作明確的轉移邏輯。非法轉移不得偷偷當成功；舊版本回應忽略；逾時保留 unknown。先列轉移表，再產生程式與針對轉移的測試案例。不要增加未描述的自動重試或導頁。

狀態機不能消除模型的隨機性，但能把輸出限制成可核對的行為。
審查時逐列對照，比讀一堆零散 setState 容易。

今日練習與筆記

找出一組不能同時為真的布林值，改寫成狀態名稱，再補上每次轉移的事件。
若某個狀態不知道怎麼離開，通常也代表使用者會卡在那裡。

下篇把這些前端行為帶進 API 契約討論吧