連鎖店系統不能複製貼上：汽車保養連鎖的資料踩雷實錄

某汽車保養連鎖品牌，全臺十幾家分店共用同一套會員與訂單系統。總部覺得這樣很聰明，一套程式管全部門市，改一次全部生效。問題是，改一次也代表錯一次全部一起錯。我們接手做系統健檢時，光是把後臺報表和實際交易資料兜起來，就抓出三種會讓人臉綠的漏洞。

新品項上線，舊白名單直接把業績吃掉

分店陸續推出新的保養方案和套裝組合，系統裡卻有一份「認列品項白名單」是很久以前寫死的。新方案名稱不在名單裡，系統邏輯判斷不到，整批訂單直接被排除在業績統計外。不是少算，是完全沒被看見。這種問題最陰險的地方在於，前臺看起來一切正常，訂單照樣成立，只有月底對帳時才會發現數字對不上，而且往往已經過了好幾個月。

• 白名單、規則表這種寫死的清單，上線後一定要有「新增品項時同步檢查」的提醒機制，不能靠人記得
• 報表的計算口徑要跟業務邏輯保持一致，例如一組套裝裡包含多項服務，不能用「單筆訂單 × 單價」簡化計算，實際上一筆訂單可能涵蓋多項服務內容，用簡化公式會嚴重低估

先出貨後付款，這種情境系統想不到

這家連鎖後來想開放到府保養預約付款，模式是師傅到府服務完才收款。系統原本的付款狀態邏輯裡有一個守衛條件：只有狀態變成「已付款」才會寫入付款時間，用意是防止重複回呼把原始付款時間覆蓋掉。但到府收款是先服務、後付款，狀態流程走的是「已完成服務」而不是「已付款」，導致這個守衛條件永遠不成立，付款時間永遠寫不進去，月結報表整批漏算這些營收。

系統邏輯是照著「正常流程」寫的，但真正會咬人的永遠是那個沒被想到的例外流程。

沒有錯誤訊息，才是最貴的錯誤

這家連鎖官網做過改版，改完之後社群分享連結一直抓不到縮圖，社群小編以為是圖檔問題重傳了三次都沒用，其實是設定裡多打了一個副檔名，圖片路徑根本是錯的，只是瀏覽器不會跳警告，看起來就是「圖片不見了」。另外一個更嚴重的是動態產生的網站地圖檔案，因為伺服器設定把這類副檔名的請求直接交給靜態檔案處理，導致自訂邏輯完全沒機會執行，搜尋引擎抓到的地圖檔案從上線那天起就是錯誤頁面，等於半年多沒有被正確收錄過。

• 社群分享抓不到圖、搜尋引擎收錄異常，這類問題不會跳錯誤視窗，只會默默流失流量，需要定期主動檢查而不是等業績掉才發現
• 伺服器設定（例如 IIS 的處理常式優先權）跟程式邏輯是兩套系統，改了程式碼不代表伺服器一定照你想的方式執行

多站共用架構，省的是工，不是責任