为何DecimalFormat模式#0.###E0未按预期格式化数值？

咱们先拆解你用的格式化模式#0.###E0：

• 这是科学计数法格式，E0表示指数部分显示1位数字（比如E2、E3这类形式）。
• 前面的#0.###是尾数的格式规则：
  • #0：尾数的整数部分至少保留1位（由0强制保证），而科学计数法的尾数范围是[1,10)，所以实际只会显示1位整数（比如1、2…9）。
  • ###：尾数的小数部分最多显示3位，多余的位数会用默认的**银行家舍入法（ROUND_HALF_EVEN）**处理。

按照这个规则，123.456789转换成科学计数法的尾数是1.23456789，要保留3位小数的话：
第四位小数是5，而且后面还有非零数字（6789），根据银行家舍入法的规则，这种情况要进1，尾数应该变成1.235，最终输出1.235E2。

但你实际得到了1.2346E2，这说明代码执行的格式化规则和你描述的#0.###E0不一致，可能的原因有：

• 你可能不小心把模式写成了#0.####E0（四位小数），这样尾数会保留四位小数，1.23456789就会被舍入成1.2346，得到你看到的输出。
• 你的代码中可能额外设置了setMinimumFractionDigits(4)，强制小数部分至少显示4位，覆盖了模式中###的限制。
• 极少数情况下，Java版本差异或Locale的特殊设置可能导致格式化行为异常，但这种情况非常罕见。

如果你确认模式确实是#0.###E0，可以检查代码中有没有其他修改DecimalFormat行为的语句，或者在干净的测试环境中运行这段代码，看看结果是否符合预期。

内容的提问来源于stack exchange，提问作者Satellite Sage