系統斷網怎麼辦?離線可用的設計思維

「網路又不會一直斷,有必要做離線功能嗎?」——會這樣問,通常是因為還沒在尖峰時段的門市經歷過網路斷線。收銀機前排著五個客人,系統轉圈圈,店員只能陪笑道歉,這五分鐘的體感比五小時還長。我們的系統支撐著實體門市的每日營運,「斷網怎麼辦」不是假設題,是設計系統時的必答題。這篇講離線可用的設計思維,以及它背後真正困難的部分:資料一致性。

先誠實評估:你的系統需要離線到什麼程度?

離線能力有成本,而且不便宜,所以第一步是分級,不是全做:

• 必須離線可用:擋在營收前面的操作。門市結帳、掃碼核銷、點餐——斷網等於停業的環節。
• 離線可讀就好:價目表、商品資訊、今日預約名單。看得到但不能改,已經解決八成的尷尬。
• 可以等網路回來:報表、後台管理、資料匯出。這些做離線是浪費預算。

大多數專案的正確答案是「關鍵路徑離線可用,其他在線再說」。全面離線化的成本,足以把專案預算翻倍。

離線設計的三個層次

一、離線快取:先讓畫面開得起來

最基礎的一層是把應用程式本體與常用資料(商品、價格、會員清單)存在裝置上,斷網時介面照常打開、查詢照常運作。網頁技術這幾年在這塊成熟很多,PWA 的快取機制就是為此而生(可參考 PWA 是什麼那篇)。這一層的設計重點是「快取什麼、多久更新」:商品價格這種會變的資料,要有版本機制,連線時增量更新,不能上線第一天存一份用到天荒地老。

二、離線寫入:操作先記下來,連線再補送

真正的挑戰從「離線時要新增資料」開始。斷網時的結帳單、新會員、庫存異動,得先寫進本地的待送佇列,網路恢復後依序補送到伺服器。這裡有兩個魔鬼細節:

• 補送要防重複。網路時好時壞的時候,一筆單可能送出去了但回應沒收到,系統重送就變兩筆。解法是每筆操作帶唯一識別碼,伺服器看到重複的就只認一次。這個機制沒做,你會在月底對帳時付出代價。
• 編號策略要先想好。訂單編號如果靠伺服器產生,離線時就發不出號。常見解法是裝置端先給臨時號(帶裝置識別避免撞號),同步後由伺服器補正式號。發票這類法規要求連號的東西更要特別設計,離線開立的規則要先跟你的發票加值服務確認清楚。

三、同步衝突:兩邊都改了,聽誰的?

最難的一層。門市 A 離線時改了某會員的電話,同時後台也改了同一個欄位,網路恢復後兩個版本撞在一起。教科書會給你很多解法,實務上我們的建議是:用業務規則消滅衝突,而不是用演算法解決衝突。例如:庫存異動一律做成「增減紀錄」而不是「覆寫數字」,兩邊的異動都成立,加總就對;會員資料指定唯一的編輯入口,其他端唯讀。真的躲不掉的衝突,誠實地留給人判斷——列出兩個版本讓管理者選,比系統自作聰明選錯好得多。

離線設計的核心不是「讓系統在斷網時能動」,而是「讓網路恢復之後,所有人對發生過的事有同一個版本的真相」。

別忘了演練

最後一個建議:離線機制做完,要真的拔網路測試,而且是照營運劇本測——斷網收三筆單、恢復、看資料對不對;同步到一半再斷一次,看會不會出現半套資料。離線功能是保險,而保險最怕的是理賠那天才發現條款沒寫好。如果你的營運場景吃不起斷網,想把這層保險做扎實,歡迎聊聊:客製化系統與 SaaS 服務。