BigDecimal构造应避免double参数，须用String或valueOf；四则运算必须调用add、subtract等方法；比较大小唯一可靠方式是compareTo；setScale和divide需按业务选RoundingMode，货币标度通常为2。
BigDecimal构造时别用double参数
直接用new BigDecimal(0.1)会导致精度污染，因为0.1这个double字面量在二进制中本就是近似值，传入后会把误差原样保留。比如new BigDecimal(0.1).toString()实际输出"0.1000000000000000055511151231257827021181583404541015625"。
正确做法是用字符串构造：new BigDecimal("0.1")。所有需要精确表达的数值，只要来源是字面量、用户输入或数据库字段（非binary类型），都应走String构造器。
- 从
double转来必须先用Double.toString(d)再构造，但更推荐源头就避免double -
BigDecimal.valueOf(double)是安全的——它内部调用了Double.toString，可作为double转BigDecimal的唯一推荐方式 - 从数据库读取
DECIMAL或NUMERIC字段时，JDBC驱动通常返回String或BigDecimal，优先取后者
四则运算必须用方法而非操作符
Java不支持BigDecimal的+、-、*、/重载，写a + b会触发自动拆箱为double再相加，彻底丢失精度和语义。
所有计算必须显式调用方法：
立即学习“Java免费学习笔记（深入）”；
- 加法：
a.add(b) - 减法：
a.subtract(b) - 乘法：
a.multiply(b) - 除法：
a.divide(b, scale, RoundingMode.HALF_UP)——除法必须指定精度和舍入模式，否则遇到无限小数（如1/3）直接抛ArithmeticException
注意multiply结果的精度是两操作数精度之和，而add/subtract结果精度是两者中较大者，这些细节会影响后续比较或存储。
比较大小不能用==或compareTo没处理null
==比较的是引用，两个值相等的BigDecimal对象用==大概率返回false；equals()虽然比较值，但会同时比较标度（scale），new BigDecimal("1.0").equals(new BigDecimal("1.00"))返回false。
真正可靠的比较只有compareTo()：
- 返回
-1、0、1，只比数值大小，忽略标度差异 - 必须确保两个对象都不为
null，否则NullPointerException - 条件判断中写
a.compareTo(b) == 0代替a.equals(b)，写a.compareTo(b) > 0代替a.doubleValue() > b.doubleValue()
setScale和divide的RoundingMode选哪个
setScale和divide都强制要求指定RoundingMode，最常用的是RoundingMode.HALF_UP（四舍五入），但它不是银行常用规则——金融场景常需RoundingMode.HALF_EVEN（银行家舍入，减少统计偏差）。
- 业务明确要求“四舍五入”时用
HALF_UP；涉及金额分账、利息累计等长期累加场景，优先考虑HALF_EVEN -
UNNECESSARY仅适用于你100%确定结果能整除的情况，比如除以100转换百分比，否则运行时报错 - 不要用
RoundingMode.DOWN或UP做金额截断，它们不满足会计上“趋近”原则，容易引发对账差异
标度（scale）设多少取决于业务：货币通常取2（分）、利率可能取6或8，但一旦设定就要全程一致，尤其在数据库字段定义、序列化协议、前后端交互中保持统一。
