健身工作室系統崩了三次才學會的教訓：資料一致性
一家連鎖健身工作室的會員點數與商品同步系統踩過的雷，從外來鍵衝突到生日欄位被偷換，拆解資料一致性問題背後的工程真相。
- 多分店系統各自建資料庫時，同一張課程表的內部代號可能完全不同，靠代號硬對接遲早炸
- 促銷折扣的計算基準沒講清楚，門檻和實際扣款會對不起來，帳務永遠有人在吵架
- 看不見的欄位限制和靜默失敗最可怕，系統會偷偷把錯的資料存成看起來正常的樣子
某家連鎖健身工作室找上我們時，狀況是這樣：總部系統和分店系統各自獨立建了好幾年，直到要打通會員資料、課程庫存、點數回饋，才發現根本是兩個世界硬湊在一起。這篇整理三個真實踩過的雷，全部去識別化，但邏輯保留，因為這些坑，任何做多據點、多系統整合的老闆都可能踩到。
雷一：兩邊資料庫的「內部代號」從來不是同一套
總部系統和分店系統各自手動建課程型別的時候，系統內部給的識別碼是不一樣的，這很正常，因為是兩個人在兩臺機器上各自建的。問題是同步程式一開始直接把識別碼原封不動搬過去，對方資料庫一插入就違反外來鍵限制，直接跳錯。
解法不是硬修那筆資料，而是換一套雙方都認得的「代號字首」當溝通語言，傳送端帶著代號，接收端拿代號去查自己本地對應的識別碼，查不到才退回舊邏輯檢查。這種設計的重點是：跨系統同步永遠不要相信對方的內部編號，要用雙方都懂的業務代號當橋樑。
雷二：促銷門檻用錯基準，帳自己對不起來
這家工作室做過「滿額送點數」活動，原本門檻是用商品原價乘數量去算，結果客人用了折扣券之後，門檻計算跟實際付款金額完全脫鉤，導致有人明明沒付到門檻金額卻拿到回饋，客服天天在處理爭議。
- 把門檻判定改成用「訂單淨實付金額」為基礎，反映真實付款狀況
- 用「命中商品原價佔全單原價的比例」去拆算應得回饋，維持分攤邏輯一致
- 預覽階段付款金額還沒確定時，退回保守估算，不亂給承諾
這件事給的教訓很直接：任何跟金錢有關的計算邏輯，一定要先確認「基準是什麼」，用錯基準不是程式錯，是需求沒講清楚，程式只是老實把錯誤放大而已。
雷三：欄位長度不夠，系統直接把你的訂單吃掉
這家工作室的線上結帳系統有陣子偶爾會莫名其妙擋單，查了半天發現是行銷廣告帶來的追蹤引數太長，超過資料庫欄位上限，系統存檔時直接丟例外，訂單就這樣消失在使用者眼前，客人只看到結帳失敗，完全不知道發生什麼事。
更誇張的是另一個案例：會員在某些嵌入式瀏覽器裡填的生日格式不對，系統沒有跳錯，而是默默把生日存成一個假日期，之後這筆假資料還會被當成正常資料顯示在會員資訊裡，形成一個沒人發現的長期汙染源。
系統不會在你面前失敗，它只會在你看不到的地方，把錯的資料存成正常的樣子。