问题
今天在网上看到一个有意思的问题，金额的数据类型用Long还是BigDecimal？
具体问题大概是这样的：关于金额的数据类型，组长认为使用BigDecimal比较稳妥，总监认为使用Long才不会出问题，然后开发认为Long用起来比较爽。
从这两个数据类型来看，这家公司使用的开发语言应该是Java，不过换成其它开发语言，也有类似的数据类型选择问题，这是一个广泛存在的问题，所以可以和大家好好聊聊。
网友方案
针对这个问题，热情的网友们从各自的经历出发，提供了很多方案。我大概总结了下，居然有十种之多，虽然有的像调侃，但都有一定的道理。相信大家也很好奇，所以这里我先分享下网友们的方案。
Long
解读：单位到分，没有小数点，也就没有小数精度的问题。而且Long取值范围也足够了。
BigDecimal
解读：大家都这么用，BigDecimal就是为精确计算而生的。用long不专业，适应性不好。
Long和BigDecimal
解读：成年人不做选择，成年人什么都要。金额、价格这些用Long，汇率、费率这些要求的小数点比较多，那就用BigDecimal。
String
解读：万物皆可string。只是处理规则需要全部自己写，高手必备的技能。
Protobuf
解读：脱离框架讲方案都是耍流氓。Protobuf里边根本就没有BigDecimal，虽然可以用string或者自定义类型来代表Java中的BigDecimal，不过性能可能要差那么一点点。
自定义
解读：架构师的好苗子。程序不是能跑起来、不出错就行了，要考虑设计能不能自然体现业务需求，好不好理解、扩展和维护。
听领导的
解读：霍金来了中国也得站起来敬酒。这根本不是技术问题，一切听领导指示，但是也要做好自我保护。
问AI
解读：紧跟时代风口。作为有追求的技术人，就应该想着怎么偷懒怎么最快，先进的生产力工具要用起来，大语言模型回答这个问题滴水不漏、手到擒来，不信你试试！
节省型
解读：节俭是美德。就几百块钱的货，又不是航母和火箭，根本用不着Long，用int、short，甚至byte就能满足。
莫名其妙
解读：这个特定芯片是说CPU做不了浮点数运算吗？还是说不同的CPU浮点数运算的算法不同？那编程语言不能直接处理这个问题吗？还需要开发者关心。不懂，真不懂，完全不懂，请有经验的大神帮解答下。
根本问题
俗话说，结局问题先得明确问题。那么这到底是个什么问题呢？归根到底还是小数的精度问题。
有时候是根本除不尽，比如10除以3；有时候是因为小数的表达问题，编程语言中带小数的数据类型一般是float和double，它们内部使用科学计数法，转换二进制的时候有可能出现无限小数位的问题，比如Javascript中的0.1+0.2算出来就不是0.3。
所以为了避免此类问题，大家想出来了各种各样的方法。
其实使用Long和BigDecimal的本质都是一样的，他们内部都是通过整数记录值，只是Long属于隐式设定小数点，BigDecimal属于显示设定小数点。
比如，使用Long表示价格时，系统约定单位是分，那么9999就代表99.99元；而使用BigDecimal表示价格时，则需要明确小数位 new BigDecimal("99.99")。
另外不管是Long还是BigDecaimal只要发生除不尽，就存在精度问题。
解决方案
这里我做个总结。
在程序中处理金额时，最佳实践通常是使用类似BigDecimal的数据类型，因为它提供了精确的小数运算能力，这对于财务计算来说非常重要。使用BigDecimal可以避免因浮点数的精度问题导致的计算误差，这些误差在金融应用中可能会导致严重的问题。
BigDecimal可以精确地表示和计算小数，它允许你定义小数点后的精度，并且提供了一系列的舍入模式。这意味着当你需要执行加减乘除时，可以控制舍入行为以符合金融计算的要求。
另一方面，虽然使用Long类型来表示金额（通常以分为单位）也是一种选择，因为它避免了小数的使用，从而也能保证精确性。但是，这种方法在表示和处理小数时就不那么直观，而且在需要进行货币转换或者涉及到小数的计算时，你必须自己管理小数点的位置。
例如，如果使用Long表示金额，你需要记住金额是以分为单位还是以元为单位，而且在报告或用户界面中显示金额时，通常需要将金额转换为以元为单位的格式，这就需要额外的计算步骤。
所以，虽然Long类型也可以用来精确地表示金额，但是为了代码的可读性、易用性和减少手动处理小数点的错误，推荐使用BigDecimal来处理金额。这是一种更安全、更灵活的方法，尤其是在需要精确计算小数时。
其它使用string或者自定义类的方案，当然也可以，只是需要更多的工作来完善数据处理的各种规则，容易出错，也不规范，为什么不使用现成的BigDecimal呢？
以上就是本文的主要内容。
关注萤火架构，提升技术不迷路！