舍入模式须按业务逻辑选定，不可随意；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 —— 避免掩盖业务逻辑漏洞。