問題

今天在網上看到一個有意思的問題，金額的數據類型用Long還是BigDecimal？

具體問題大概是這樣的：關于金額的數據類型，組長認為使用BigDecimal比較穩(wěn)妥，總監(jiān)認為使用Long才不會出問題，然后開發(fā)認為Long用起來比較爽。

從這兩個數據類型來看，這家公司使用的開發(fā)語言應該是Java，不過換成其它開發(fā)語言，也有類似的數據類型選擇問題，這是一個廣泛存在的問題，所以可以和大家好好聊聊。

網友方案

針對這個問題，熱情的網友們從各自的經歷出發(fā)，提供了很多方案。我大概總結了下，居然有十種之多，雖然有的像調侃，但都有一定的道理。相信大家也很好奇，所以這里我先分享下網友們的方案。

Long

解讀：單位到分，沒有小數點，也就沒有小數精度的問題。而且Long取值范圍也足夠了。

BigDecimal

解讀：大家都這么用，BigDecimal就是為精確計算而生的。用long不專業(yè)，適應性不好。

Long和BigDecimal

解讀：成年人不做選擇，成年人什么都要。金額、價格這些用Long，匯率、費率這些要求的小數點比較多，那就用BigDecimal。

String

解讀：萬物皆可string。只是處理規(guī)則需要全部自己寫，高手必備的技能。

Protobuf

解讀：脫離框架講方案都是耍流氓。Protobuf里邊根本就沒有BigDecimal，雖然可以用string或者自定義類型來代表Java中的BigDecimal，不過性能可能要差那么一點點。

自定義

解讀：架構師的好苗子。程序不是能跑起來、不出錯就行了，要考慮設計能不能自然體現業(yè)務需求，好不好理解、擴展和維護。

聽領導的

解讀：霍金來了中國也得站起來敬酒。這根本不是技術問題，一切聽領導指示，但是也要做好自我保護。

問AI

解讀：緊跟時代風口。作為有追求的技術人，就應該想著怎么偷懶怎么最快，先進的生產力工具要用起來，大語言模型回答這個問題滴水不漏、手到擒來，不信你試試！

節(jié)省型

解讀：節(jié)儉是美德。就幾百塊錢的貨，又不是航母和火箭，根本用不著Long，用int、short，甚至byte就能滿足。

莫名其妙

解讀：這個特定芯片是說CPU的位寬不一樣嗎？比如16位、32位CPU加減乘除的結果可能不同。不懂，真不懂，完全不懂這條評論在說什么問題，請有經驗的大神幫解答下。

根本問題

俗話說，結局問題先得明確問題。那么這到底是個什么問題呢？歸根到底還是小數的精度問題。

有時候是根本除不盡，比如10除以3；有時候是因為小數的表達問題，編程語言中帶小數的數據類型一般是float和double，它們內部使用科學計數法，轉換二進制的時候有可能出現無限小數位的問題，比如Javascript中的0.1+0.2算出來就不是0.3，因為浮點數無法精確的表達0.1。

所以為了避免此類問題，大家想出來了各種各樣的方法。

其實使用Long和BigDecimal的本質都是一樣的，都是避免使用浮點數進行表達，只是Long屬于隱式設定小數點，BigDecimal屬于顯示設定小數點。

比如，使用Long表示價格時，系統(tǒng)約定單位是分，那么9999就代表99.99元；而使用BigDecimal表示價格時，則需要明確小數位 new BigDecimal("99.99")。

另外不管是Long還是BigDecaimal在進行除法運算時，只要發(fā)生除不盡，就存在精度問題。

解決方案

這里我做個總結。

在程序中處理金額時，最佳實踐通常是使用類似BigDecimal的數據類型，因為它提供了精確的小數運算能力，這對于財務計算來說非常重要。使用BigDecimal可以避免因浮點數的精度問題導致的計算誤差，這些誤差在金融應用中可能會導致嚴重的問題。

BigDecimal可以精確地表示和計算小數，它允許你定義小數點后的精度，并且提供了一系列的舍入模式。這意味著當你需要執(zhí)行加減乘除時，可以控制舍入行為以符合金融計算的要求。

另一方面，雖然使用Long類型來表示金額（通常以分為單位）也是一種選擇，因為它避免了小數的使用，從而也能保證精確性。但是，這種方法在表示和處理小數時就不那么直觀，而且在需要進行貨幣轉換或者涉及到小數的計算時，你必須自己管理小數點的位置。

例如，如果使用Long表示金額，你需要記住金額是以分為單位還是以元為單位，而且在報告或用戶界面中顯示金額時，通常需要將金額轉換為以元為單位的格式，這就需要額外的計算步驟。

所以，雖然Long類型也可以用來精確地表示金額，但是為了代碼的可讀性、易用性和減少手動處理小數點的錯誤，推薦使用BigDecimal來處理金額。這是一種更安全、更靈活的方法，尤其是在需要精確計算小數時。

其它使用string或者自定義類的方案，當然也可以，只是需要更多的工作來完善數據處理的各種規(guī)則，容易出錯，也不規(guī)范，為什么不使用現成的BigDecimal呢？