循環產生的條件

三個條件同時成立時產生困住使用者的重試循環：

錯誤持續存在。暫時性錯誤（網路閃斷）會在重試中自行恢復。持續性錯誤（伺服器已關閉）不會因重試而改變。

UI 只提供重試選項。Error 畫面上唯一的按鈕是「重試」，沒有返回、取消或其他替代路徑。

沒有重試次數上限。使用者可以無限重試，每次都失敗，每次都回到同一個 error 畫面。

app_tunnel 修復前的 error 和 disconnected 狀態就是這個模式 — 有重連按鈕但沒有 back 按鈕。重連失敗時使用者只能再次重連，無法返回首頁（U.C1）。

逃生口設計

每個 error 畫面至少兩個選項

重試按鈕旁邊放一個退出路徑。「重試」+「返回首頁」是最小組合。使用者想繼續嘗試就重試，想離開就返回。

這和畫面狀態矩陣的退出路徑要求一致 — 每個狀態至少一條退出路徑（定義與填寫方法）。Error 狀態的退出路徑包括重試（回到 connecting 狀態）和返回（離開當前畫面）。

自動重試達上限後切換 UI

自動重試有固定上限（例如 3 次或 5 次）。達到上限後，UI 從「正在重試」切換到「連線失敗」，提供手動重試和退出路徑。

切換 UI 的意義是向使用者傳達「自動恢復已經嘗試過了，需要你來判斷接下來怎麼做」。使用者可能知道問題的原因（忘了開伺服器、WiFi 沒連上），手動修正後再重試。

提供問題診斷線索

在 error 畫面提供足夠的資訊讓使用者判斷是否值得繼續重試。「伺服器沒有回應」和「認證已過期」是不同的問題 — 前者可能重試會成功（伺服器正在重啟），後者重試不會改變結果（需要重新登入）。

診斷資訊幫助使用者做出正確決策：繼續重試、返回重新操作、或完全離開。

替代操作路徑

除了重試和返回，某些場景可以提供第三條路。連線特定伺服器失敗時，提供「選擇其他伺服器」的選項。認證失敗時，提供「用其他方式登入」的選項。

替代路徑把「失敗 → 重試同樣的操作」擴展成「失敗 → 嘗試不同的操作」，增加使用者脫離困境的機會。

檢查方法

用畫面狀態矩陣檢查 error 和 retry 狀態：

1. 找到所有 error 狀態（矩陣中 type = error 的行）
2. 檢查每個 error 狀態的「可用操作」欄 — 是否除了「重試」之外還有其他操作
3. 檢查每個 error 狀態的「退出路徑」欄 — 是否有離開當前畫面的路徑
4. 操作欄只有「重試」且退出路徑為空 = 潛在的 retry loop

這個檢查在設計階段就能完成，成本遠低於實機測試時才發現使用者被困住。

下一步路由

• 錯誤訊息如何引導使用者行動 → 錯誤訊息撰寫原則
• 重試策略的選擇 → Retry 機制 UX
• 畫面狀態矩陣的退出路徑檢查 → ux-design 模組一 畫面狀態機
• Mock 遮蔽 error 場景的問題 → testing 模組一 測試策略分層
• Error 事件的分類與收集 → monitoring 模組一 監控心智模型