舍入模式须按业务逻辑选定，不可随意；HALF_UP适用于通用四舍五入场景，UP/DOWN分别表示远离/靠近零取整，UNNECESSARY用于精度校验。
直接说结论：舍入模式不是“选对就行”，而是“按业务逻辑定规则”。用错一个模式，比如该用 HALF_UP 却用了 UP，在金融场景中可能让每笔交易多收 0.01 元——日均万笔就是 100 元误差，一年超 3.6 万元。
先搞清两个核心动作的区别
BigDecimal 的舍入发生在两种典型操作中，但机制不同，容易混用：
-
setScale()：用于已有数值的精度调整（如格式化显示、中间值截断），必须指定小数位数和舍入模式。例如：
amount.setScale(2, RoundingMode.HALF_UP) -
divide()：除法必须显式带精度与模式，否则遇到 1÷3 这类无限小数会直接抛
ArithmeticException。正确写法是：dividend.divide(divisor, 2, RoundingMode.HALF_UP)
注意：加、减、乘法不强制要求舍入参数；唯独除法，不指定就崩。
HALF_UP 是默认安全选择，但不是万能解
它对应日常“四舍五入”：舍去部分 ≥ 0.5 就进位，负数同理（-2.5 → -3）。适用于报表统计、通用计费、用户可见金额展示。
- ✅ 正确示例：
new BigDecimal("12.345").setScale(2, RoundingMode.HALF_UP)→ 12.35 - ✅ 负数也一致：
new BigDecimal("-12.345").setScale(2, RoundingMode.HALF_UP)→ -12.35 - ⚠️ 注意陷阱：它不解决统计偏差。大量含 .5 的数据反复四舍五入，会系统性偏高。高频批量计算（如利息日结）建议改用 HALF_EVEN（银行家舍入）。
UP 和 DOWN 不是“向上/向下取整”，而是“远离零/趋向零”
这是最容易误解的点。它们不看正负号方向，只看绝对值变化：
-
UP：绝对值一定变大 →
3.1 → 4，-3.1 → -4（都更远离 0） -
DOWN：绝对值一定变小或不变 →
3.9 → 3，-3.9 → -3（都更靠近 0） - ? 实战场景：UP 常用于费用类计算（确保不低估应收），DOWN 用于保守估值（如授信额度预估、风险准备金计提）。
别忽略 UNNECESSARY —— 它是精度校验开关
当你明确要求“结果必须能整除，不能有小数”，就用它。一旦需要舍入，立刻抛 ArithmeticException，帮你提前暴露数据异常。
- ✅ 合规检查场景：合同约定单价 × 数量必须为整元，可写：
total.divide(unitPrice, 0, RoundingMode.UNNECESSARY) - ❌ 若 unitPrice 是 9.99、total 是 19.98，运行时立即报错，而不是静默返回 2 —— 避免掩盖业务逻辑漏洞。
