网友方案
金额到底用 Long 还是 BigDecimal？这个问题在 Java 后端圈子里几乎成了“月经贴”。有人拿实际项目经验说事，也有人从工程设计角度分析。下面整理了网友们的十种方案，看看哪一种更对你的场景。
Long
解读：把单位定为分，金额就没有小数点，自然也不存在小数精度问题。Long 的取值范围也足够覆盖绝大多数业务金额。
BigDecimal
解读：BigDecimal 本来就是为精确计算设计的，大家都这么用。如果选 Long，多少显得不够“专业”，后续需求变动时适应性也差一些。
Long 和 BigDecimal
解读：成年人当然可以全都要。价格、金额这类字段用 Long，汇率、费率等需要多位小数的场景再上 BigDecimal，各取所长。
String
解读：万物皆可 String。只是相关的校验、转换、计算规则都得自己写，适合愿意折腾的高手。
Protobuf
解读：脱离框架谈方案确实有点耍流氓。Protobuf 里压根没有 BigDecimal，要么用 string 表示，要么自定义类型，性能上多少会有些代价。
自定义
解读：这算是架构师的思路。程序不是能跑起来、不出错就够了，还得看设计能不能清晰表达业务需求，好不好理解、扩展和维护。金额类最好能显式带上币种和最小单位，避免歧义。
听领导的
解读：这可能是真实职场里最优先的“方案”。技术上可以较真，但最终还是得听领导的，必要时也留好记录保护自己。
问 AI
解读：与其自己纠结，不如把问题丢给大语言模型。作为想提高效率的技术人，工具该用就用，GPT 回答这类问题通常又快又稳。
节省型
解读：节俭是美德。如果业务金额就几百块，用 int、short 甚至 byte 也未尝不可，没必要一上来就 Long 或 BigDecimal。
莫名其妙
解读：这条提到 BigDecimal 在特定芯片环境下可能因硬件差异产生与预期不同的结果，用 Long 反而更稳妥，只是需要额外处理小数转换。
原文 https://juejin.cn/post/7314928953193578505 | 
发表于 4 天前
|
查看: 10|
回复: 0
