java怎么保留小数：分场景用对应方法规避精度bug

前段时间做电商后台的金额计算功能，反复纠结java怎么保留小数，最开始凭着模糊的认知瞎写代码，结果线上数据频频出现精度错乱的问题，几分钱的误差堆在一起，直接导致对账对不上，折腾了整整一下午才把问题彻底理顺。

最开始的想法特别简单，觉得小数保留不就是截取固定位数嘛，直接用强制类型转换处理就行。每次计算完double类型的金额数据，就粗暴截取两位小数赋值，当时天真的以为这样就能搞定所有场景，完全没考虑过浮点类型本身的精度缺陷。double存储小数的时候本身就会存在微小的数值偏差，再加上没有任何规则的强制截取，原本应该是10.25元的精准数据，经常莫名其妙变成10.24元或者10.26元，测试的时候零星的误差没放在心上，上线批量数据跑起来之后，微小误差直接被放大，对账报表里密密麻麻全是异常数据，看得人头大。

一开始压根没找对问题根源。

后来跟风用了网上很多人推荐的DecimalFormat来格式化小数，照着现成的代码模板敲完，确实能固定显示两位小数，当时还以为终于彻底解决了这个麻烦。可专门跑了几组临界边界的测试数据之后，新的问题又冒了出来，部分数值的取舍完全没有规律，该进位的不进位，该保留的直接舍弃，数据结果乱七八糟。

折腾好久才搞明白，DecimalFormat默认的舍入规则并不是日常业务通用的四舍五入，它的自适应取舍策略很不稳定，专门针对边界数值出错，而且这个方法还有个很隐蔽的问题，就是在高并发接口场景下线程不安全，项目初期访问量小没暴露问题，一旦用户请求变多，就会随机出现格式化失效的情况，这也是很多新手踩的隐形大坑。

普通日常场景根本没必要搞这么复杂。

现在日常开发里，普通数据展示、普通数值统计的需求，我全都直接用String.format方法，写一句%.2f的格式配置，就能稳定保留两位小数，默认就是标准的四舍五入规则，适配百分之八十的普通业务场景。这个写法特别轻便，一行代码就能实现，没有线程安全的隐患，也不用额外配置繁杂参数，不用花时间研究底层规则，上手就能用，实用性拉满。

如果是涉及资金结算、交易核算这种对精度要求极高的核心场景，就不能用简单的格式化方法了，必须用BigDecimal来处理。先把double、float类型的数值转为BigDecimal对象，手动设置保留位数和HALF_UP标准四舍五入模式，能从根源规避浮点精度丢失的问题。只是这个写法会繁琐一点，必须手动指定舍入规则，绝对不能偷懒用默认配置，不然依旧会出现数据偏差，白忙活一场。

那天改完所有出错的代码，跑完几十组对账测试用例，看着控制台全部通过的提示，默默关掉了折腾一下午的代码窗口。