二手書電商踩過的雷：一個 Email 兩個帳號是怎麼發生的

某二手書電商找上我們的時候，講的是「幫我們優化一下後台」，聽起來人畜無害。實際挖下去，才發現後台裡藏著幾個活了好幾年的資料炸彈，隨時準備炸客服、炸會計、炸信任。這篇不談玄乎的數位轉型口號，只講幾個具體到能複製貼上的踩雷現場。

訂閱訂單複製母單，發票也跟著複製

這家電商有訂閱制服務，像是每月自動幫你補書單。續期訂單的做法是把母單整包複製一份，改個日期就當新訂單送出去。問題是，工程師用了物件對物件的整包複製工具，母單上的發票號碼、發票日期、發票狀態，全部原封不動一起複製過去。

• 母單已經開過發票才續期，續期單直接繼承第一期的發票號碼
• 發票查詢列表顯示續期單已開立，發票號碼看起來煞有介事
• 實際去金流服務商那邊查詢，卻顯示這張訂單根本沒開過發票
• 自動開票排程只挑發票狀態是空白的訂單，續期單因為狀態非空，永遠不會被排進去開票

結果就是兩套系統各說各話，會計對帳對到懷疑人生，客人打來問發票在哪裡，客服也答不上來。這種問題不會在測試環境爆炸，因為測試環境通常不會跑到「母單先開票、再產生續期單」這個時序，只有真實營運跑久了才會現形。

點數扣款失敗，系統選擇沉默是金

這家的會員點數可以在結帳時折抵金額。原始設計裡，扣點失敗這件事居然沒有留下任何紀錄，程式碼直接吞掉例外，訂單照樣成立，只是點數沒真的扣到。等於客人白拿了折抵，公司默默少收一筆錢，而且完全沒有告警機制去通知任何人。

系統不報錯不代表沒出錯，它只是幫你把錯默默地藏起來，直到帳對不上為止。

更麻煩的是，同一筆點數還能在多張待付款訂單裡被重複折抵。客人下兩張訂單都用同一筆點數殺價，系統沒有把「已被使用中」的點數鎖起來，等於一筆點數可以無限次分身。這類漏洞不是駭客攻擊，是系統設計時少想了一個狀態鎖的問題，卻要靠營運數字異常才會被發現。

改 Email 這種小功能，才是唯一性檢查的照妖鏡

多數團隊在「新註冊」的入口都會記得檢查 Email 是否重複，這是基本常識。但這家電商在後台有個「客服代客戶修改資料」的功能，改 Email 這條路徑完全沒做唯一性檢查。於是客服可以把客人的信箱改成任何字串，包括改成另一個已存在的帳號在用的信箱，兩個帳號就此共用同一組聯絡方式，訂單通知、密碼重設信全部開始送錯人。

資料完整性不是找出來的，是设計出來的

好的系統設計不是沒有 bug，是失敗的時候，它會誠實地告訴你哪裡壞了。