起因

周天正在帶娃吭哧吭哧爬山，一個電話呼過來了：“線上緊急bug，app價格是錯的，差了10倍，每單虧200多”，然后diss了開發和測試的質量。
我表示很懵逼啊！項目是一個月前離職同事交接過來的。線上穩定運行一個多月了也沒有改動過這個邏輯啊！
然后電話仔細一溝通，只能說離譜，太他喵的離譜了。線上一個月前發版。穩定的錯誤運行了1個月，直到用戶反饋怎么扣錢扣的少了。

啥騷操作導致的呢？

我們有一個中臺用來配置這些購買套餐相關的配置信息。
原始的標準呢就是中臺前端輸入元（元比較符合大眾認知）。數據存儲的分（int存儲不丟精度，準確，穩定）（很完美的設計此處需要掌聲??）。
我們調用微信支付，微信貨幣的單位是分，我們直接按照數據庫存儲的原始數據傳遞給支付組件（nice）。

后來我們對接了海外項目，海外印尼的項目，支付的貨幣是印尼盾（IDR）,
對接支付的開發呢沿用了微信的調用邏輯，直接取數據庫的值傳遞給印尼的midtrans支付。
中臺測試驗證過程中呢發現？哎我想要支付100Rp，我不能輸入100，我必須輸入1.才能正常支付。如果想要支付1Rp,必須輸入0.01.（中臺輸入的元和實際調用支付的分差了100倍。IDR這個地方又不需要做這個單位轉換）
測試這樣湊合過了，產品也這樣湊合過了，驗收的時候緊急上線也這樣湊合過了，安排了下個版本修復。

下個版本誰修復呢？bug提交給了中臺，我們都沒有被通知到，說中臺設置了1，數據庫保存了100，這不行，要所見即所得，設置1數據庫保存1，調起支付為1.
嗯，這樣看起來完全沒毛病。（因為當時只有印尼的midtrans支付）

沒毛病個大頭鬼啊！
這他喵的數據庫存儲的基準單位都更換了（原來是0.01基準單位，現在變成了基準單位），只是通知了各個前端和中臺的后臺，愣是沒有通知到我們這邊開發。
關鍵是還存在版本并行開發， 一個新的版本mpay對接澳門通支付的版本。
mpay支付，數據庫存儲的分（我們認為），調用mpay支付,mpay需要貨幣單位為元。后臺做了??0.01操作。
無巧不成書，巧合在什么地方呢？mpay測試環境不支持支付驗證。
正式環境驗證需要聯系澳門的同事支付。三重buff疊加。嗯，我們的支付少了100倍。100倍啊！

復盤

開發的鍋：內部溝通存在問題， 關鍵變更特別是影響金額的重大變更沒有落實到紙面通知到位（郵件/文檔等）
測試的鍋：測試覆蓋不全。
產品的鍋：上線驗收及線上運行監控不到位

以后涉及金額相關如何做？

支付相關涉及金額相關，

頁面設置大家理解共識的基準單位：CNY（元）/Rp（印尼盾）/MOP（澳門元）/USD（美元）
數據庫存儲，單位為0.01基準單位(部分場景存儲0.0001基準單位），比如1分=0.01元。
    優點： int/long存儲，計算方便，無需考慮精度丟失。準確，穩定。
    缺點： 前端展示/其他計算需要手動進行相關的倍數還原計算。

為啥不按照基準單位存儲？
當時產品也說:印尼的最小幣值就是20了，都沒有人民幣分對應的概念。澳門我們包年費用就是199元，那3毛2分的我們看不著。
我們后續推出月租呢？再推出日租呢？分要不要毛要不要？
基準單位后面一般情況下是要冗余2-4位的，用來進行做對應的計算冗余。

為啥部分場景要按照0.0001基準單位存儲？
國家電網的價格=0.5769元/度。當用電量比較大的時候小數點后四位才能表示的更加精準。
我們計算應收帳款的時候，針對10度電收費5.76元，剩余的0.009被舍棄掉，但是計算過程中需要精度更高才能計算的更精準。部分場景多冗余幾位還是很有必要的。

印尼的最小單位就是印尼盾了，為啥Rp不直接入庫原始數據，針對CNY/MOP數據庫按照分存儲？
中臺是一個統一維護的平臺， 針對不同的貨幣單位，做了不同的處理方式，后續數據對接就容易混亂，不如就奠定一個0.01基準單位的基調，后續都按照這個來處理。

業務側用int處理還是long處理？
建議用long來處理，因為不知道公司會不會去對接津巴布韋幣，我怕我小小的int不夠用。
現在對接印尼盾int就已經有點捉襟見肘了。
int最大值：2147483647 去掉冗余的2位=21474836（2千萬）, 1元=2100印尼盾，int最大能表示到中國1萬元。