问题
最近网上有个问题讨论得很热：金额的数据类型，到底该用 Long 还是 BigDecimal？
从这两种类型来看，这公司用的应该是 Java 语言。不过换成其他语言，也有类似的类型选择烦恼，所以这是个相当普遍的问题，值得我们一起捋一捋。
网友方案
针对这个问题，热心的网友们结合自身经历给出了好些方案。我梳理了一下，居然归纳出十种，有的明显是调侃，但各自都藏着道理。相信你也很好奇，下面就先来看看这些脑洞大开的解法。
Long
解读：单位统一到分，没有小数点，自然就没有精度问题。而且 Long 的取值范围也足够覆盖业务需求了。
BigDecimal
解读：大家约定俗成，BigDecimal 就是为精确计算而生的。用 Long 显得不够专业，适应性也差一截。
Long 和 BigDecimal 混用
解读：成年人当然全都要。金额、价格这些整数场景用 Long；碰到汇率、费率这种小数点特别多的复杂运算，再祭出 BigDecimal 不迟。
String
解读：万物皆可 String。只不过处理逻辑得自己全写，这可是高手的必备内功了。
Protobuf
解读：脱离框架谈方案，都是耍流氓。Protobuf 里压根儿没有 BigDecimal，虽然能用 string 或自定义类型去模拟 Java 的 BigDecimal，但性能上多少会吃一点亏。
自定义
解读：这是 架构 师的好苗子。程序不是跑起来不出错就行，还得看设计能不能自然体现业务需求，好不好理解、扩展和维护。
听领导的
解读：霍金来了也得站起来敬酒。这压根不是技术问题，一切听领导指示，不过同时也得做好自我保护。
问 AI
解读：紧跟时代风口。有追求的技术人，就该琢磨怎么偷懒、怎么最快。大语言模型处理这种问题滴水不漏、手到擒来，不信你试试！
节省型
解读：节俭也是种美德。就几百块钱的流水，又不是造航母火箭，根本用不着 Long，int、short 甚至 byte 就绰绰有余。
莫名其妙
解读：BigDecimal 在特定芯片环境下，可能会因芯片不同跑出与实际运算相左的结果，从这个角度看 Long 反倒更稳妥——只不过表达小数时需要额外转换。
作者：萤火架构
来源：juejin.cn/post/7314928953193578505
| 
发表于 2 小时前
|
查看: 6|
回复: 0
