累计舍入误差必然发生，须全程高精度计算、仅最终舍入，用字符串初始化BigDecimal，按会计准则在指定环节统一舍入而非每期截断。
计息计算中，累计舍入误差不是“偶尔出错”，而是“必然发生”——只要每期都独立舍入，误差就会像雪球一样越滚越大。真正可靠的方案不是选更“准”的舍入模式，而是控制舍入时机、统一精度基准、分离计算与展示。
利息计算必须先算准，再舍入
常见错误是每期都用 setScale(2, RoundingMode.HALF_UP) 截断中间结果。比如年利率6%按日计息，本金100万，连续365次 multiply(每日利率).setScale(2)，最终会比理论值少几毛甚至几块钱。
- 正确做法：全程保留高精度（如 scale=6 或 8），仅在最终输出或写库前做一次舍入
- 示例：每日利息 = 本金 × 日利率（不设 scale）→ 累加到总利息（仍不设 scale）→ 最终总利息 .setScale(2, RoundingMode.HALF_EVEN)
- 银行家舍入（HALF_EVEN）比 HALF_UP 更适合长期复利场景，能抵消部分系统性偏差
复利/多期计息务必用幂运算替代循环乘法
循环调用 multiply() 不仅慢，还放大舍入误差。比如月复利12期，用12次乘法 vs 用 pow(12)，后者底层基于二分算法，中间过程精度更高、路径更可控。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
BigDecimal自带pow(int n)，但仅支持整数幂；若需小数幂（如1.5年），建议用Math.pow配合字符串构造（仅限初始值），或引入 Apache Commons Math 的DecimalFunction - 避免对每次复利结果调用
setScale—— 它会让每期的“毫厘之差”变成下期的“本金基数”
本金与利率必须用字符串初始化
哪怕只是写 new BigDecimal(0.06)，也会把二进制近似值（如0.060000000000000005）带入计算，后续所有利息都从这个偏差起点开始漂移。
立即学习“Java免费学习笔记（深入）”；
- 利率统一用字符串：
new BigDecimal("0.06")或BigDecimal.valueOf(6).divide(BigDecimal.valueOf(100)) - 本金同理：
new BigDecimal("1000000.00")，而非new BigDecimal(1000000.00) - 注意：
BigDecimal.valueOf(double)内部做了字符串转换，比直接用 double 构造安全，但仍不如显式字符串可靠
业务规则决定舍入位置，而非技术便利
法律和会计准则往往规定“利息按日计提、按月结息、按季支付”，这意味着：日利息可暂不舍入，月汇总后按实际天数加总再舍入到分，支付时以该舍入值为准——而不是每天就四舍五入到分。
- 对照《企业会计准则第17号——借款费用》：利息资本化金额应“按实际利率法计算”，强调“计算过程不得人为截断”
- 实操建议：建模时区分
interestAccruedUnrounded（高精度累计）和interestPayable（最终应付，已按规则舍入）两个字段 - 日志中同时记录舍入前/后值，便于审计追溯误差来源
