Java收银程序四舍五入保留两位小数问题：相似代码结果不同求解

嘿，我完全懂你现在的纠结——明明两段代码看起来差不多，结果一个能正确把价格四舍五入到两位小数再转成整数存储，另一个却不行，这种细节上的差异真的很磨人。咱们先从你的核心需求入手：把用户输入的价格（比如3.21）转成整数形式（321），本质是要先精确四舍五入到两位小数，再放大100倍转成整数对吧？

根据这类问题的常见坑，大概率是两段代码在浮点数精度处理或者四舍五入逻辑上有细微差别，我给你拆解几个最可能的原因：

1. 浮点数精度陷阱：double的先天缺陷 #

如果你的问题代码是直接用double类型处理价格，然后简单乘以100再强制转整数，就会踩这个坑。比如：

// 有问题的代码示例
double price = 3.21;
int totalCents = (int)(price * 100); // 实际得到320，不是321！

为什么？因为double是二进制浮点数，没法精确表示很多十进制小数——比如3.21在内存里实际存储的是一个近似值（类似3.2099999999999994），乘以100后就变成320.99999999999994，这时候用(int)强制转换会直接截断小数部分，而不是四舍五入，结果自然不对。

而能正常工作的代码，大概率用了Math.round()来处理：

// 正常工作的代码示例
double price = 3.21;
int totalCents = (int)Math.round(price * 100); // 得到321

Math.round()会把浮点数近似到最近的整数，即使因为精度问题得到320.99999999999994，它也会正确四舍五入成321。

2. 四舍五入逻辑的差异 #

另一种可能是，两段代码用了不同的四舍五入方式：

• 正确的那段用了Math.round()或者BigDecimal的显式四舍五入模式；
• 有问题的那段只是用了Math.floor()（向下取整）或者直接强制转换（截断），自然达不到四舍五入的效果。

3. 输入处理方式不同 #

如果一段代码是直接把用户输入的字符串转成BigDecimal（处理货币的最佳实践），另一段用double接收输入，结果也会天差地别：

// 推荐的精确处理方式
String userInput = "3.21"; // 直接拿用户输入的字符串，避免double精度损失
BigDecimal price = new BigDecimal(userInput);
// 明确指定四舍五入模式（HALF_UP就是日常的四舍五入）
BigDecimal totalCents = price.multiply(new BigDecimal("100")).setScale(0, RoundingMode.HALF_UP);
int total = totalCents.intValue(); // 精确得到321

BigDecimal是专门为精确十进制计算设计的，完全不会有double的精度问题，这也是收银系统这类场景的标准做法。

总结你的问题原因 #

你遇到的情况，90%以上是因为：

• 有问题的代码依赖了double的直接运算+强制转换，触发了浮点数精度陷阱；
• 正常工作的代码要么用了Math.round()做了正确的四舍五入，要么用了BigDecimal做精确计算。

如果能贴出两段代码的具体内容，我可以帮你更精准地定位，但根据常见场景，上面的分析应该能帮你找到问题所在啦。

内容的提问来源于stack exchange，提问作者Andrew Macmillan