企业官网建设流程全解析

1. 从一次账面不平说起：为什么double做不了精确计算

先讲个真实经历。某次帮一个团队排查线上账单问题，用户提交订单时金额总是偶尔多出0.01元，运营那边对账对不上，查了很久最后发现祸根是double。代码里写的是0.1 * 3，开发觉得天经地义应该等于0.3，结果一打印出来是0.30000000000000004。更离谱的是，0.1 + 0.2的结果是0.30000000000000004，而0.3 - 0.1是0.19999999999999998。那一瞬间我就知道，这不是一个bug，而是一整套浮点数运算体系的固有缺陷。

问题的根源在于计算机底层都用二进制存数。十进制里的0.1，换算成二进制是一个无限循环小数，就像用十进制无法精确写出1/3一样。double只有52位有效二进制位，存不下无限循环，只能截断，所以每次运算都带着一个极小的误差。日常计算误差无所谓，但涉及金额、税率、库存数量、科学计量等场景，误差累积起来就会出大事。

Java里解决这个问题的标准方案就是BigDecimal。它用任意精度的整数加上小数点位置来表示小数，比如123.45在内部被拆成12345和精度2来管理，所有加减乘除都走整数运算，从根源上杜绝了二进制近似问题。

可以肯定地说，凡是涉及钱的代码，都应该用BigDecimal，而不是double或float。这篇内容会从构造方法、运算API、舍入模式、比较逻辑、序列化兼容、性能权衡到实战封装，把BigDecimal完整讲一遍，重点是把那些文档里查不到、但实际开发中一定会遇到的坑都翻出来。

2. 构造BigDecimal的正确姿势：三个构造方法的巨大差异

BigDecimal一共有十多个构造方法，日常开发里真正高频使用的其实就三个：new BigDecimal(int)、new BigDecimal(String)、new BigDecimal(double)。很多人因为不了解三者差异，第一步就埋下了精度隐患。

2.1 new BigDecimal(0.1)与new BigDecimal("0.1")的天壤之别

直接看代码：

BigDecimal d1 = new BigDecimal(0.1); System.out.println(d1); // 输出 0.1000000000000000055511151231257827021181583404541015625 BigDecimal d2 = new BigDecimal("0.1"); System.out.println(d2); // 输出 0.1

new BigDecimal(0.1)接收的是double字面量，这个double的值本身就是0.1的二进制近似，BigDecimal只能忠实地还原它，把那个误差完整呈现出来。而new BigDecimal("0.1")接收的是字符串，解析过程完全按照十进制逐位处理，得到的才是数学意义上精确的0.1。

所以第一条铁律就是：不要用new BigDecimal(double)初始化业务字段，除非你明确知道自己在做什么。如果非要从double转，就用BigDecimal.valueOf(double)，它内部实际执行的是new BigDecimal(Double.toString(val))，先转字符串再解析，同样安全。

2.2 预设常量与零值的正确使用

BigDecimal提供了几个常用预设常量：BigDecimal.ZERO、BigDecimal.ONE、BigDecimal.TEN。这几个常量既是不可变对象，又省去了构造开销，还能避免重复新建零值对象。但有一个细节很容易忽略：BigDecimal.ZERO的精度是0，而new BigDecimal("0.00")的精度是2。

BigDecimal a = BigDecimal.ZERO; System.out.println(a.scale()); // 0 BigDecimal b = new BigDecimal("0.00"); System.out.println(b.scale()); // 2

这个差异在setScale和除法运算时会影响结果精度。比如需要用保留两位小数的格式做计算时，BigDecimal.ZERO.add(amount)的结果精度会跟随amount，但如果是BigDecimal.ZERO.divide(...)就可能出现精度截断问题，后面细说。

2.3 静态工厂方法与构造方法的取舍

除了构造方法，Java 9之后BigDecimal多了valueOf(long)和valueOf(double)两个静态工厂。valueOf(long)没有解析开销，适合整数转换；valueOf(double)内部做了字符串中间转换，虽然性能略低于直接构造，但安全性远高于new BigDecimal(double)。

我自己团队内部的代码规范里就明确了一条：业务代码中禁止出现new BigDecimal(double)，一律使用BigDecimal.valueOf或字符串构造。这条规则直接写进了代码检查脚本，因为这条坑实在太隐蔽，等到线上账不平再排查，代价就大了。

有一类场景可以例外使用new BigDecimal(double)，比如在做科学计算、需要对齐double原始值的精确表示时，才需要完整还原那个二进制近似值。业务系统里基本用不到。

3. 四则运算的底线：为什么divide总是要指定舍入模式

BigDecimal的运算API设计得相对简洁：add、subtract、multiply、divide、pow、remainder等，底层都是把小数转成整数与精度分别计算，再统一处理结果尺度。但很多新手会在divide这一步翻车，一翻就是异常。

3.1 不指定精度和舍入模式的divide必抛异常

看这段：

BigDecimal a = new BigDecimal("1"); BigDecimal b = new BigDecimal("3"); BigDecimal c = a.divide(b);

运行直接抛ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.。原因是1除以3是无限循环小数，BigDecimal的精度是有限的，算不出精确的有限位数结果，又不知道该按多少位截断、按什么规则舍入，只好放弃治疗。

解决思路是显式指定结果精度和舍入模式：

BigDecimal c = a.divide(b, 4, RoundingMode.HALF_UP); // 结果 0.3333

第二个参数是小数位数，第三个参数是舍入规则。这个约束看似繁琐，其实是JDK在保护你——它强制你想清楚结果要保留几位，避免真正上线后出现无限循环误差。

3.2 加减乘的精度规则

add和subtract的结果精度按两操作数中较大的scale保留，multiply的结果精度是两操作数精度之和：

BigDecimal a = new BigDecimal("1.23"); // scale = 2 BigDecimal b = new BigDecimal("4.5"); // scale = 1 a.add(b); // 1.23 + 4.5 = 5.73，scale = 2（取max(2,1)） a.multiply(b); // 1.23 * 4.5 = 5.535，scale = 3（2+1）

大多数业务场景下，加减乘的结果自然落在预期精度范围内，不需要额外处理。但除法由于可能存在无限小数，必须额外配置，这也是JDK有意为之。

3.3 为什么建议统一走MathContext

当项目里多个地方调用divide时，每个人写4、写2、写不同的舍入模式，代码风格零散不说，行为还可能不一致。更稳妥的做法是引入MathContext统一管理精度策略：

MathContext mc = new MathContext(10, RoundingMode.HALF_UP); BigDecimal result = a.divide(b, mc);

MathContext的构造参数是总有效数字位数（不是小数位数），比如new MathContext(10, RoundingMode.HALF_UP)表示结果保留10位有效数字。这对于科学计算、统计分析中的连续运算特别适合，但对金额计算这种固定小数位的场景，我更习惯于直接用divide(BigDecimal divisor, int scale, RoundingMode roundingMode)，语义更直白。

3.4 除法实战中的一个边界情况

还有一个容易被忽略的点：除以0的处理。BigDecimal继承自Number，但做除法时如果除数是0，会抛ArithmeticException / by zero。这个行为看起来自然，但在批量数据处理中，某些行数据除数为0时没有捕获异常，会导致整个任务失败。我在处理报表数据时习惯先做一次除数判断：

if (denominator.compareTo(BigDecimal.ZERO) == 0) { // 记录异常数据，填充默认值或跳过 }

注意不要用denominator.equals(BigDecimal.ZERO)，因为new BigDecimal("0.00").equals(BigDecimal.ZERO)为false，这个差异会在后面比较章节详细展开。

4. 精度控制与八种舍入模式：到底该用哪一个

精度控制是BigDecimal使用的核心，但大多数人只认识setScale和RoundingMode.HALF_UP。实际上，舍入模式一共有八种，彼此之间的差异在特定场景下非常致命，选错一个，账目就会多一分少一分。

4.1 setScale的两类用法

setScale有两个重载：

BigDecimal a = new BigDecimal("3.14159"); a.setScale(2, RoundingMode.HALF_UP); // 结果 3.14 a.setScale(0, RoundingMode.HALF_UP); // 结果 3

不带舍入模式的setScale(2)有个限制：如果原值小数位本来就大于2，会抛ArithmeticException，所以日常使用更推荐带上舍入模式。另外，setScale(int newScale, RoundingMode mode)返回的是新对象，原对象不变，BigDecimal不可变性的一个具体体现。

4.2 八种舍入模式逐一点评

下面这张表整理了JDK 8之后RoundingMode枚举的全部值，以及它们的行为差异：

4.3 银行家舍入HALF_EVEN到底在解决什么

很多人第一次见到HALF_EVEN会觉得奇怪：四舍五入不是天经地义吗？为什么银行要搞这种"五成双"的规则？

原因在于统计意义上的公平。四舍五入对.5这个边界总是进位，长期大量计算时会产生系统性偏差，累积的结果会偏高。而HALF_EVEN的做法是：如果舍入位恰好是5，就根据前一位的奇偶决定——前一位是偶数则舍去，是奇数则进位。这样.5在大量数据中约有一半进位、一半舍去，整体误差趋近于零。

RoundingMode.HALF_EVEN new BigDecimal("2.5").setScale(0, RoundingMode.HALF_EVEN); // 2，前一位2为偶数 new BigDecimal("3.5").setScale(0, RoundingMode.HALF_EVEN); // 4，前一位3为奇数

银行业、金融统计的标准里经常采用这种规则。普通电商项目的订单金额计算，差异微乎其微，用HALF_UP也没有问题，但如果你做的是对账系统、证券清算这类对统计偏差敏感的系统，HALF_EVEN更稳妥。

4.4 实际业务中的精度策略建议

金额累加场景，我一般按“计算过程中不做精度裁剪，只在展示和入库时保留2位”的策略进行：

• 一次运算产生的中间结果不急着setScale，让精度自然携带；
• 最终入数据库前统一保留2位，用HALF_UP或HALF_EVEN按业务约定选一个；
• 如果有跨系统对账需求，双方必须约定同一舍入模式，否则两边各算各的，永远对不上。

有个真实的例子：一个打折活动，折扣价计算时保留6位小数，入库时保留2位，前端展示时发现部分订单比手工计算多了0.01。排查后发现，另一个系统在计算时直接保留了2位，两边累计的舍入次数不同，误差就出来了。解决方案就是约定所有系统统一在最终环节只舍入一次。

5. 比较与转换：equals、compareTo与toString的三个暗坑

BigDecimal的坑不只是运算，比较和转换同样处处是雷。这两个环节的错误往往不会抛异常，而是安静地给出错误结果，比异常更难排查。

5.1 equals与compareTo的差异是知名陷阱

BigDecimal a = new BigDecimal("1.0"); BigDecimal b = new BigDecimal("1.00"); System.out.println(a.equals(b)); // false System.out.println(a.compareTo(b)); // 0

equals不仅比较数值，还比较精度（scale）。1.0和1.00在数值上完全相等，精度不同，equals返回false。而compareTo只比较数值大小，所以返回0。业务上做金额、数量的相等判断，基本都用compareTo，但很多人习惯了基本类型的==，随手会写成a.equals(b)——一旦双方精度不一致，直接翻车。

写一个安全的金额相等判断工具方法：

public static boolean isEqual(BigDecimal a, BigDecimal b) { if (a == null || b == null) { return a == b; } return a.compareTo(b) == 0; }

compareTo方法内部会忽略精度差异，本质是把两者转成同一精度后再比较整数部分。这也是为什么推荐把金额比较全部收敛到一个工具方法里，避免散落各处的误用。

5.2 hashCode与equals不一致引发集合查找失效

一旦你重写了equals逻辑（或者误用了默认的equals做业务判断），还有一个连锁问题：BigDecimal的hashCode和它默认的equals是配套的，即1.0与1.00的hashCode不同。如果你把它们存入HashSet或HashMap作为key，1.0和1.00会被当成两个不同的键。这在金额统计、商品计数对账时会产生诡异的结果。

处理方式有两种：要么所有金额在入口处统一stripTrailingZeros()后再进入集合，要么干脆用String（标准格式化后的字符串）作为集合key，不要直接用BigDecimal。

// 入口统一去尾零 BigDecimal normalized = amount.stripTrailingZeros();

注意stripTrailingZeros()也有一个边界：new BigDecimal("0.00").stripTrailingZeros()的结果scale可能是负数，比如0E-2，后续再参与运算时可能有意料之外的表现。实际使用时要对结果做一次setScale(2)兜底。

5.3 toString与科学计数法的惊吓

BigDecimal的toString在某些情况下会输出科学计数法，这是很多新手的盲区：

BigDecimal a = new BigDecimal("1E+3"); System.out.println(a.toString()); // 1E+3 BigDecimal b = new BigDecimal("1000"); System.out.println(b.toString()); // 1000

而这个1E+3如果直接拼到JSON、导出Excel、生成PDF里，用户看到的就是一串莫名其妙的“1E+3”，连生成的二维码都可能错了。正确做法是使用toPlainString()，它永远输出普通十进制表示：

System.out.println(new BigDecimal("1E+3").toPlainString()); // 1000

凡是金额展示、文件导出、接口返回，我都建议强制使用toPlainString()。需要注意的是，toString和toPlainString在JSON序列化时可能被框架自动调用，如果你用的是某些不熟悉BigDecimal的序列化库，务必在配置层面指定序列化器，否则依然可能踩科学计数法的坑。

6. 真实业务中的落地经验：序列化、数据库与性能取舍

BigDecimal毕竟是一个对象类型，在真实业务里它要穿过JSON、数据库、前后端交互各个环节，每一步都有潜在的转化坑。这里只聊那些我做过、踩过、验证过的经验。

6.1 与JSON序列化的兼容问题

常见的几个JSON库在序列化BigDecimal时行为略有不同：

跨语言系统交互时，BigDecimal被序列化成数字还是字符串，会直接影响对端解析精度。我的经验是：如果对端是Python、JavaScript这类浮点数类型的语言，金额字段一律以字符串传输，否则一进JavaScript就变浮点数，精度瞬间归零。在Java服务内部用BigDecimal，出了服务边界改用String。

6.2 数据库中的推荐存储方式

数据库层面存储金额，一般有两种方案。一种是DECIMAL(10, 2)，Java端映射为BigDecimal；另一种是BIGINT存储最小单位（比如分），Java端用Long运算，展示时再转BigDecimal。

用DECIMAL的优点是语义直白、数据库可以直接SUM和比较，缺点是对应驱动返回的精度处理需要额外注意某些连接字符串参数。用BIGINT的优点是计算飞快、没有精度争议，缺点是要自己维护单位换算，而且SQL里直接做金额加减时容易忘除以100。

团队规范上，我推荐线上数据库统一用DECIMAL，字段阈值按业务上限调大（常见DECIMAL(12, 2)或DECIMAL(14, 4)），而不是一律2位小数，为将来扩展留余地。产品如果允许折扣、优惠分摊、多币种，小数位建议保留4位甚至6位，展示时再格式化。

6.3 BigDecimal的性能到底差在哪里

BigDecimal的每次运算都会创建新对象，涉及整数数组操作，性能确实低于double，但绝没有传说中那么夸张。在普通Web服务里，一个请求做几十次金额运算，耗时占比可以忽略。真正需要注意的是循环中创建大量BigDecimal的场景，比如批处理几万行数据、大量调用金额累加时，GC压力和对象创建开销会明显上升。

优化手段有几类：

• 复用常量，比如BigDecimal.ZERO、BigDecimal.ONE，避免每次new BigDecimal(0)；
• 批量计算时用局部变量减少属性写入；
• 避免频繁在BigDecimal和String之间互相转换，那比纯运算更贵；
• 如果单机吞吐高到需要压榨性能，可以考虑用整数类型的分值做运算，只在边界转BigDecimal。

我实际测试过一个场景：用BigDecimal循环累加10万次，耗时大约在几十毫秒到一两百毫秒之间，具体取决于机器。这个量级对绝大多数业务系统来说都可以接受。

7. 完整实战：一个经过打磨的金额计算工具类

前面讲了原理和坑，最后上一个我在团队里沉淀了很久的金额工具类。这个工具类覆盖了构造、加法、减法、乘法、除法、比较、格式化、JSON输出等高频场景，可以直接复制到项目里按需裁剪。

7.1 基础工具类的完整代码

import java.math.BigDecimal; import java.math.RoundingMode; import java.util.Objects; public class MoneyUtils { private static final int MONEY_SCALE = 2; private static final RoundingMode DEFAULT_ROUNDING = RoundingMode.HALF_UP; private static final BigDecimal HUNDRED = new BigDecimal("100"); private MoneyUtils() { } /** * 安全构造：禁止直接 new BigDecimal(double) */ public static BigDecimal of(double value) { return BigDecimal.valueOf(value); } public static BigDecimal of(String value) { if (value == null || value.trim().isEmpty()) { throw new IllegalArgumentException("金额字符串不能为空"); } return new BigDecimal(value.trim()); } /** * 金额加法，保留默认精度 */ public static BigDecimal add(BigDecimal a, BigDecimal b) { return nullSafe(a).add(nullSafe(b)); } /** * 金额减法，保留默认精度 */ public static BigDecimal subtract(BigDecimal a, BigDecimal b) { return nullSafe(a).subtract(nullSafe(b)); } /** * 金额乘法，结果保留两位小数 */ public static BigDecimal multiply(BigDecimal a, BigDecimal b) { return nullSafe(a).multiply(nullSafe(b)).setScale(MONEY_SCALE, DEFAULT_ROUNDING); } /** * 金额除法，强制指定精度与舍入模式 */ public static BigDecimal divide(BigDecimal a, BigDecimal b, int scale) { if (nullSafe(b).compareTo(BigDecimal.ZERO) == 0) { throw new IllegalArgumentException("除数不能为零"); } return nullSafe(a).divide(nullSafe(b), scale, DEFAULT_ROUNDING); } /** * 等值判断：使用 compareTo 忽略精度差异 */ public static boolean equals(BigDecimal a, BigDecimal b) { if (a == null || b == null) { return a == b; } return a.compareTo(b) == 0; } /** * 格式化输出，固定两位小数 */ public static String format(BigDecimal amount) { if (amount == null) { return "0.00"; } return amount.setScale(MONEY_SCALE, DEFAULT_ROUNDING).toPlainString(); } /** * 分转元 */ public static BigDecimal fenToYuan(long fen) { return BigDecimal.valueOf(fen).divide(HUNDRED, MONEY_SCALE, DEFAULT_ROUNDING); } /** * 元转分 */ public static long yuanToFen(BigDecimal yuan) { return yuan.setScale(MONEY_SCALE, DEFAULT_ROUNDING) .multiply(HUNDRED) .longValue(); } private static BigDecimal nullSafe(BigDecimal value) { return value == null ? BigDecimal.ZERO : value; } }

这个类有几个设计点值得说明。第一，所有入口都做了null安全兜底，避免调用方忘记判空导致NPE。第二，乘法和除法在返回前统一做了精度裁剪，保证外部拿到的金额永远符合“两位小数”的契约。第三，提供分和元互转的方法，防止团队里有人手动除100、乘100导致精度出问题。

7.2 大额与性能场景的进一步演进

如果项目需要处理超大金额（超过万亿级）或者极高并发下的金额运算，工具类还可以继续演进：

• 内部改用BigInteger存储最小单位值，只在输入输出时做BigDecimal转换；
• 金额运算使用线程安全的无状态工具方法，不持有BigDecimal成员变量；
• JPA/Hibernate映射字段统一自定义AttributeConverter，统一处理数据库和实体之间的转换。

这些优化建议都不需要一开始做，等真到了性能瓶颈再引入也不迟。核心是先把精度这条路走对，再谈优化。

7.3 我在团队里最想强调的三条红线

最后把实战中整理出的三条红线放在这里，每条都是真实事故换来的：

第一条，任何现金、余额、交易相关的字段，类型必须是BigDecimal，禁止double与float。这条写进代码评审规则，发现一个驳回一个。

第二条，除法必须有舍入模式，加法减法乘法在需要固定精度输出时统一setScale。不要相信默认行为，默认只会给你“你以为对，其实不对”的结果。

第三条，数据库、JSON、日志里显示的金额，统一走toPlainString或格式化工具。任何环节出现1E+3这种形式，都必须当作事故处理。

这几条红线看起来很基础，但在团队协作中，每个人对精度的理解参差不齐，只有形成规范并用工具强制约束，才能真正避免那些让人心力交瘁的账目异常。

8. 最后聊几个我踩过的BigDecimal冷门问题

写到这里，BigDecimal的主要内容基本都覆盖了，但还有几个冷门问题，是我自己实际遇到过、查了很久才搞明白的，一并分享出来。

8.1 BIgDecimal与原子类的组合

AtomicReference<BigDecimal>可以用来做无锁的金额累计，但很多人不知道AtomicReference用CAS更新时，BigDecimal的不可变性反而带来一个便于并发的优点：每次更新都创建新对象，不会出现半更新状态。不过千万注意，更新逻辑里犯一个常见的错，把加减结果算出来后忘了用compareAndSet循环重试，多线程下会丢更新。

private final AtomicReference<BigDecimal> balance = new AtomicReference<>(BigDecimal.ZERO); public void add(BigDecimal delta) { while (true) { BigDecimal prev = balance.get(); BigDecimal next = prev.add(delta); if (balance.compareAndSet(prev, next)) { return; } } }

8.2 stripTrailingZeros与科学计数法在输出中的纠缠

前面提到过stripTrailingZeros可能引入负数scale。举一个具体例子：

BigDecimal a = new BigDecimal("100"); BigDecimal b = a.stripTrailingZeros(); System.out.println(b.scale()); // -2

此时如果用默认的BigDecimal序列化输出，可能变成1E+2，前端拿到会懵。遇到需要去尾零又保持普通输出时，建议统一在格式化阶段处理，而不是直接拿stripTrailingZeros的返回值到处传递。

8.3 优先用long还是BigDecimal？一个务实的决策

很多资深开发建议金额用long存“分”，理由是性能好、无精度问题。这个说法有道理，但不完全对。如果你的业务只是加减乘除、不涉及复杂舍入、不跨系统交换小数，用long确实香。但一旦涉及百分比计算、折扣分摊、税费折算、汇率转换，long的整数运算反而更容易出错，因为舍入时机、单位换算都要自己管理，代码可读性也差。

我的建议是：内部模块可以用long做性能优化，但所有服务接口的入参出参统一用BigDecimal。先把边界定义清楚，内部怎么折腾是内部的事，对外保证精度和语义的一致性。这个设计在微服务架构里尤其重要，因为跨服务传递的字段类型一旦定成String或BigDecimal，后续改型成本极高。

另外，不管是long还是BigDecimal，都要注意前端JavaScript的整数安全范围是Number.MAX_SAFE_INTEGER即9007199254740991。如果金额按“分”存且超过这个范围，后端JSON输出时又会变成丢失精度的浮点数，所以跨端传输金额字符串方案依然是目前最稳的选择。

8.4 一个隐藏很深的格式化陷阱：国际化与千分位

金额格式化如果用到java.text.NumberFormat或DecimalFormat，在特定Locale下会自动添加千分位分隔符。例如：

DecimalFormat df = new DecimalFormat("#,##0.00"); df.format(new BigDecimal("1234567.89"));

输出是1,234,567.89，看起来很正常，但如果你把这个字符串再塞回new BigDecimal(...)，直接抛异常，因为逗号不是合法数字字符。所以任何“把格式化后的字符串转回数值”的逻辑，都必须先移除千分位逗号，或者干脆只用toPlainString做传输格式，展示格式化才用DecimalFormat。

8.5 BigDecimal在Lambda和流式处理中的使用建议

使用Java 8的Stream做金额汇总很常见，但有一个性能痛点：如果对每个元素都调用reduce(BigDecimal::add)，会产生大量的中间对象。建议如下：

BigDecimal total = items.stream() .map(Item::getAmount) .reduce(BigDecimal.ZERO, BigDecimal::add);

这样确实能工作，但在大列表下性能一般。更优的做法是先用mapToLong把金额转成“分”累加，最后一次性除以100转回BigDecimal：

long totalFen = items.stream() .mapToLong(item -> yuanToFen(item.getAmount())) .sum(); BigDecimal total = fenToYuan(totalFen);

前提是业务固定按分累计且不会溢出long（总金额不超过9.22亿亿分）。这个方法在批处理账单汇总时，性能提升非常明显。

8.6 关于代码规范的一点个人坚持

我见过不少团队的代码里金额计算散落在各种Service、Controller里，有的用double，有的用BigDecimal，有的用long，风格完全不一致。后面接手排查账目问题的人，面对一锅大杂烩，连从何查起都不知道。

所以我在团队里坚持做了一件事：所有金额操作统一走一个金额工具类或领域服务，禁止在业务代码里直接new BigDecimal、直接进行加减乘除、直接比较大小。为此写了一个简单的代码检查规则，扫描业务包下的BigDecimal直接使用限制。一开始团队成员觉得多余，但经历过一次跨月对账事故后，大家都觉得这个约束值得。

BigDecimal本身不难，难的是团队每个人对精度的认知统一。如果你是一个人维护项目，至少自己心里要有这根弦，知道哪些写法会留隐患，哪些写法是安全的。这篇内容如果能帮你少踩几个坑，就不算白写。