处理高精度金融数据应使用bigdecimal，创建时只用字符串或valueof(double)，运算需调用add/subtract/multiply/divide（除法须指定精度和舍入模式），标度与舍入模式须显式控制，并确保数据库用decimal、前端传字符串。
处理高精度金融数据，核心是避免浮点误差、控制舍入逻辑、确保全程可追溯。Java中没有“魔法类”，只有BigDecimal这一被行业验证的可靠方案——它不是“更好用的double”，而是从底层就按十进制建模的数值系统。
创建BigDecimal：只认字符串，拒绝double字面量
错误写法会把0.1的二进制误差直接带入对象：
BigDecimal wrong = new BigDecimal(0.1); // 实际值是 0.1000000000000000055511151231257827021181583404541015625
正确方式只有两种：
- 用字符串构造（最安全，推荐所有金额初始化）：
new BigDecimal("199.99") - 用
BigDecimal.valueOf(double)（内部做了字符串转换优化，适用于已知无精度污染的double变量，如Double.parseDouble("199.99")结果）
运算必须调用方法，且结果是新对象
BigDecimal不可变，所有运算返回新实例，原值不受影响：
- 加减乘：直接调用
add()、subtract()、multiply()，无需指定精度 - 除法必须指定小数位数和舍入模式，否则可能抛
ArithmeticException：amount.divide(divisor, 2, RoundingMode.HALF_UP)（保留2位，四舍五入） - 不要用
/或*运算符——Java不支持重载，编译会报错
标度（scale）与舍入模式必须显式控制
金融场景中，“保留两位小数”不是格式化需求，而是业务规则。标度决定小数点后几位，舍入模式决定怎么取舍：
-
RoundingMode.HALF_UP：日常计费、发票金额最常用（0.5进1） -
RoundingMode.HALF_EVEN：银行家舍入，用于利息分摊等需长期平衡的场景（0.5向偶数靠） -
setScale(2, mode)用于统一结果精度，例如乘法后可能产生4位小数，必须缩放到2位才能入库或展示
与数据库和前端协作的关键细节
高精度计算不是孤立环节，要贯穿全链路：
- 数据库字段类型必须是
DECIMAL(p,s)（如DECIMAL(19,2)），不能用FLOAT或DOUBLE - JDBC读写时，MyBatis或JPA默认能正确映射
BigDecimal，但注意检查配置是否启用了useBigDecimals=true（尤其MySQL Connector/J旧版本） - 前端接收金额时，建议传字符串而非数字，避免JSON序列化再次引入浮点误差（如
{"amount":"99.99"}）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
