題目與範圍
為經常斷網或流量成本高的使用者設計離線優先產品。答案要覆蓋目標人群、核心任務、離線行為、同步預期、衝突處理、MVP 和指標。
把離線優先當作產品承諾，而不是快取清單。Android 指南將其定義為核心功能全部或關鍵子集在無網時仍可用；web.dev 也強調請求無法完成時要向使用者清楚說明狀態。
面試官考察什麼
面試官考察使用者分層、約束下的優先級、資料狀態信任，以及把體驗選擇連接到結果的能力。好的回答會區分「離線可用」和「稍後同步」，讓限制可見，而不是承諾整套產品無網運行。
作答前需要確認的問題
- 哪些使用者、地點、裝置和網路模式在範圍內？
- 必須離線完成的單一任務是什麼：閱讀、建立、編輯、採集還是分享？
- 資料是否私密、協作、受監管或安全關鍵？
- 內容允許多舊，兩台裝置同時編輯時怎麼辦？
- 儲存、電量、流量和支援成本有哪些硬約束？
30 秒回答框架
「我會從經常在盲區記錄現場資料的工作人員開始。MVP 支援查看分配任務、建立草稿、附加小型證據並展示同步狀態，但不承諾離線即時協作。本地資料源作為即時真相，待同步佇列用冪等鍵上傳，並把衝突交給使用者確認。先衡量斷網任務完成率、同步成功率、衝突解決時間、流量和支援請求，再擴大範圍。」
分步深入
第一步：按網路和任務分層
不要把「網路差的人」當作一個群體。按任務、斷網頻率、裝置能力和失敗代價分層。記錄憑證的配送員、記錄病歷的醫護人員和查看票據的旅客需要不同離線保證。
第二步：按離線價值排序任務
按緊急程度、頻率、資料大小和可逆性給任務排序。先做窄的關鍵路徑：查看準備好的任務、採集輸入、儲存草稿或讀取已下載內容。協作編輯和大媒體檔案可後置。
第三步：明確產品狀態
使用使用者能行動的標籤：已儲存到裝置、等待同步、已同步、需要處理衝突或上傳失敗。web.dev 提醒灰色或含糊的離線狀態會讓使用者困惑；要明確現在可用什麼、仍需網路什麼。
第四步：定義資料真相來源
離線優先時，本地資料源應作為即時真相，再與伺服器協調。說明哪些欄位權威、如何比較版本，以及同步前使用者能否撤銷本地改動。
第五步：設計同步契約
把變更放入帶冪等鍵的佇列，只對安全操作重試，並展示進度。決定自動同步、手動同步還是兩者兼有。網路失敗時保留草稿，不要把本地儲存偽裝成伺服器已發布。
第六步：選擇衝突策略
獨立欄位可以逐欄位合併；共享狀態或數量更適合版本檢查和衝突頁面，而不是靜默最後寫入。要判斷衝突是否足夠少、能否展示兩個版本而不洩露敏感資料。
第七步：定義 MVP 和灰度
首發只選一個人群、一個關鍵任務和有限本地資料。透過功能開關試點，測試飛行模式、弱網延遲，並在擴大保留量或附件大小前補齊恢復路徑。
第八步：設定結果和護欄指標
主指標可以是斷網完成目標任務的成功率，以及同步確認耗時。護欄包括資料遺失報告、未解決衝突、儲存壓力、電量、流量和支援請求。要與聯網基線比較，並按網路品質分組。
權衡與邊界
權衡一：新鮮度還是可用性
展示稍舊的任務列表可能勝過什麼都沒有，但時間戳和新鮮度承諾必須可見。安全關鍵或金融資料可能要求線上校驗，不能樂觀展示。
權衡二：本地儲存還是隱私
更多本地資料更有用，但裝置遺失時暴露面更大。最小化欄位、加密敏感內容、過期下載，並提供清晰的刪除和退出行為。
權衡三：自動同步還是使用者控制
自動同步省事；計費流量或共用裝置使用者需要控制。提供預設值，並在必要時支援暫停或僅 Wi-Fi 同步。
失敗演練與演進計畫
演練一：裝置離線一週
定義什麼會過期、什麼仍可編輯以及佇列保留多久。使用者應知道本地記錄是否仍有效，是否需要重新確認。
演練二：兩台裝置修改同一記錄
用具體例子展示衝突策略。自動合併會隱藏重要變化時保留兩份值，並衡量解決時長。
演練三：同步成功但伺服器拒絕變更
展示帶原因和下一步的失敗狀態。保留本地草稿，阻止無限重試，並提供安全修正路徑。
常見錯誤與追問
錯誤一：把離線當技術清單
先定義使用者任務和失敗代價，再考慮 Service Worker 或本地資料庫等實作。
錯誤二：承諾完全一致
說清關鍵子集和有意排除項。無限離線範圍會帶來儲存、隱私和支援問題。
錯誤三：隱藏同步狀態
使用者無法區分儲存和發布，就無法信任結果。使用基於行動的狀態、時間戳和可檢查的重試路徑。
錯誤四：所有衝突都最後寫入
實作簡單，卻可能抹掉重要工作。只有業務影響低且可恢復時才使用。
錯誤五：只測聯網留存
離線功能可能提升現場任務完成率，卻不改變日活。埋點斷網會話、同步完成和資料遺失投訴。
錯誤六：沒有恢復演練就發布
上線前測試飛行模式、慢網路、儲存已滿、時鐘變化、憑證過期和中斷上傳。