花藝訂閱平臺的點數系統大手術：不可逆切換前我們在怕什麼

有家做花藝訂閱服務的品牌找上我們，會員每次訂閱、續訂、推薦朋友都能累積點數折抵下期花束。系統跑了幾年，點數帳本的寫入邏輯散在十幾個角落，有人下單累積、有人手動核可加點、還有舊表跟新表各記一份，帳怎麼對都對不齊。客戶要的不是修 bug，是把整套點數帳本重做，換血但不能停診。

雙寫十六天，才敢按下不可逆

換血最怕的不是寫新代碼，是切換那一刻。舊系統跟新系統同時運作一段時間，新舊帳本雙寫，所有加點扣點都比對過才算數。我們設計了六項驗證指標，本機測、正式站也測，連續十六天零差異才判定新帳本可以獨當一面。不是因為龜毛，是點數等於錢，算錯一分都可能變成客訴或超額兌換的漏洞。

切換開關做成 config 驅動，平常預設維持舊寫，部署當下才在低峰時段把開關翻掉。這個決定刻意選在部署腳本裡而不是後臺設定裡，因為後臺改設定容易忘記改回來、容易多人誤觸，部署即切換至少留了一個明確的時間點跟一份紀錄可以回溯。

手動複製欄位，漏了就是漏了

另一個常見的雷，是資料傳遞用手動一個個欄位複製，而不是用物件對應工具自動轉換。花藝平臺的會員資料就出過這種事：訂閱時填的偏好花材、送花對象關係這幾個欄位，資料庫裡明明有值，API 卻回傳空白。原因很簡單，這支程式是老員工手寫的欄位對照表，新增欄位時沒有人記得回頭補。編譯不會報錯，測試也測不出來，因為程式邏輯完全正確，只是漏抄了幾行。

• 手動欄位複製的地方一定要寫註解提醒，標明「新增欄位請回來加這裡」
• 能用自動對應工具就別手刻，省下的時間都會在未來還債
• 發現一處漏欄位，先假設同源的其他地方也可能漏，不要只補眼前這個

查詢效能的鍋，常常不是程式的錯

花藝平臺後臺的商品搜尋曾經慢到七秒起跳，CPU 直接衝滿。工程師第一直覺通常是懷疑程式邏輯寫爛，但這次真正的問題是資料庫的統計資訊過期，導致查詢優化器誤判，把一個應該高效執行的計畫，搞成全表掃描還套了迴圈重複執行。改法不是重寫邏輯，而是把原本一次查詢裡混雜兩個子集合的寫法拆開，讓查詢形狀固定，優化器不會亂猜。這種問題最麻煩的地方在於，它不會每次都發生，統計資訊剛好過期才會爆，平常測試環境資料量小根本測不出來。

系統遷移不是換一套程式，是換一套讓人晚上睡得著的信任機制。沒有雙寫比對、沒有回溯紀錄的不可逆切換，叫賭博不叫工程。