选对 roundingmode 要依据业务需求：金额展示用 half_up，账务用 half_even，计费倾向 up/ceiling，库存用 down/floor，校验用 unnecessary；正负数行为需特别注意；除法和 setscale 必须显式传参；half_down 是“五舍六入”，非保守四舍五入。

选对 RoundingMode 不是看哪个名字顺眼，而是看业务要什么结果、容不容错、负数怎么处理。

先看场景定大方向

不同业务对舍入的“倾向性”完全不同：

• 用户看到的金额展示：用 HALF_UP（四舍五入），符合直觉，比如 19.995 元显示为 20.00 元
• 银行账务、统计报表：优先用 HALF_EVEN（银行家舍入），长期运算能抵消偏差，避免系统性多计或少计
• 计费类系统（如云服务按量付费）：倾向 UP 或 CEILING，确保不低估应收，例如 1.01 GB 流量按 2 GB 计费
• 库存、积分、整数配额等截断场景：用 DOWN 或 FLOOR，比如 9.8 个可用积分 → 取 9 个
• 校验精确值（如配置项必须整除）：用 UNNECESSARY，一旦需舍入就抛异常，快速暴露数据问题

正负数行为必须核对

有些模式对负数的处理和直觉相反，容易踩坑：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• UP：远离零 → −1.1 → −2（不是 −1），适合“绝对值向上”的计费逻辑
• DOWN：向零截断 → −1.9 → −1，比 FLOOR 更“宽松”
• CEILING：向正无穷 → −1.1 → −1，正数向上、负数“变大”，常用于最小起订量
• FLOOR：向负无穷 → −1.1 → −2，正数向下、负数“变小”，适合下限控制

除法和 setScale 必须显式传参

这两个操作不指定 RoundingMode 就会直接失败：

• ❌ bigDec.divide(another, 2) → 编译报错（缺第三个参数）
• ❌ value.setScale(2) → 运行时抛 ArithmeticException（除非刚好整除）
• ✅ 正确写法：dividend.divide(divisor, 2, RoundingMode.HALF_UP)
• ✅ 正确写法：value.setScale(2, RoundingMode.DOWN)

别拿 HALF_DOWN 当“保守四舍五入”

HALF_DOWN 是“五舍六入”，不是“更谨慎的四舍五入”：

• 1.235 → 1.23（舍），但 1.236 → 1.24（入）
• 它会让整体结果系统性偏低，只在特定合规要求（如某些税务规则）中使用
• 日常开发中误用 HALF_DOWN 替代 HALF_UP，会导致金额持续少算

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南