離線運作：低網路環境必備的系統設計

有一類系統，從設計第一天起就要假設「網路不存在」。

不是因為網路不好，而是因為它根本不可靠——出勤現場、偏遠山區、災難應變現場、地下室倉庫。在這些地方，你的系統如果需要連回總部伺服器才能動，它就是一個有問題的設計。

「離線支援」跟「離線優先」是兩件事

大多數人說的「支援離線」，是在系統建好之後，發現在某些環境用不了，才回頭加上離線功能。這種做法幾乎都會遇到麻煩：資料結構沒有為同步設計，快取的邊界不清楚，使用者操作離線版本後回到線上，資料衝突的處理完全沒考慮過。

「離線優先（Offline First）」是另一回事。它的假設是：網路是一種你偶爾能用到的資源，不是你可以依賴的基礎設施。

這個假設翻轉了很多決策。資料先存本地，再找機會同步。功能設計圍繞著「沒有網路的時候，使用者還需要做什麼」。

最常見的是在設備上跑一個輕量的本地服務，負責接受前端請求、讀寫本地資料庫。設備本身就是一個小型伺服器，不需要出去就能完整運作。

另一種是把服務部署在同一個區域網路（LAN）裡的一台機器上，區域內的所有設備都連這台機器，不出外網。這適合有固定場域但網路不穩定的情境，比如工廠、急救站、船上。

還有一種更極端的做法是邊緣運算（Edge Computing）——把運算能力放在最靠近資料來源的地方，減少對中央伺服器的依賴。這在 IoT 場域很常見，感測器收到的資料先在本地處理、過濾、分析，只把需要的結果往上送。

離線容易，同步難。

當設備重新連線，要把本地發生的事情送回去，同時要接收中央系統在這段時間的更新。如果兩邊同時修改了同一筆資料，誰的版本算數？

這個問題沒有一個通用答案，但有幾個常見的處理策略：

時間戳記 + 後寫優先：誰的修改時間比較晚就用誰的。簡單，但在時間不準確的設備上會出問題。

版本號 + 衝突偵測：每筆資料帶一個版本號，只要版本不一致就標記為衝突，讓使用者或系統決定怎麼合併。

只增不改（Append-Only）：資料只能新增，不能修改。這樣同步就沒有衝突問題，代價是資料量增長快，查詢邏輯比較複雜。

我們在做嘉義 DMAT 物資系統的第三期時，選的是本地端網路部署。打包區自己架一台機器，所有操作都在這台機器上跑，完全不依賴外部網路。這不是因為技術上複雜，而是因為在出勤現場，任何依賴網路的流程都是一個潛在的斷點——這個斷點不能存在。

不是每個系統都需要這樣設計，也不應該。離線優先的代價是複雜度——本地儲存、同步邏輯、衝突處理，都是額外的工程量。

值得考慮的情境：

不需要的情境：

判斷的核心問題只有一個：如果網路斷了，使用者被擋住了多嚴重？ 如果答案是「完全沒辦法工作」而且這個情境真實存在，那這個問題值得在設計初期就正面處理，而不是等到上線後回頭補。