PHP 8.4 RoundingMode 怎么迁移：round() 新模式、负数与金额验收

订单金额从分转成元时，最怕的不是少保留一位小数，而是不同服务对“刚好一半”采用了不同规则。PHP 8.4 给 round() 增加了 RoundingMode 枚举和四种新模式，旧代码里那个整数 mode 也不再适合靠猜。升级前把正数、负数和金额边界跑一遍，结果会比只看函数签名可靠。

先确认升级前后到底改了什么

PHP 8.4 的变化可以拆成两个门槛：一是多了四种方向模式，二是非法 mode 的处理从“悄悄按默认规则算”变成了异常。前者解决表达能力，后者暴露隐藏配置错误。线上如果把 mode 从环境变量或数据库读取，第二个变化更值得优先回归。

getMessage(), PHP_EOL;
}

HalfEven 会把一半位置收敛到偶数，正负数都会参与同一条规则。测试不要只断言“结果是 2”，还要断言错误 mode 能被测试捕获，否则配置拼写错误可能一直藏在默认值里。

四种新模式怎么对应真实业务

新枚举成员不是四个更好记的常量，而是把“方向”写进了代码。向零适合截断展示值，远离零适合保守计费；正无穷和负无穷则适合明确的上下取整规则。

命名时尽量跟业务规则走，不要把 PositiveInfinity 简化成“向上”后再套到负数上，因为负数的直觉最容易把团队带偏。代码评审里直接看到枚举名，通常比看到一个整数常量更容易发现取舍。

金额场景：先处理单位，再决定舍入方向

金额计算最好先统一到分或厘，再做整数运算；如果确实需要对浮点值调用 round()，要把精度和模式同时写明。下面的例子模拟折扣后金额，专门保留一个负数退款场景。

 %8.2f%n", $value, settle($value));
}

这里的关键不是选择了哪一种模式，而是把模式固定成业务契约。若财务规则要求“退款永远不多退”，就不能直接把 HalfEven 当作安全默认值，应该改成经过财务确认的方向模式，并为正负输入分别写断言。

负 precision 也要放进回归用例

round() 的 precision 可以是负数，表示在小数点左侧按十位、百位取整。库存汇总、报价分档和报表脱敏都可能用到这一点，但迁移时最容易只测试两位小数。

 ', round($value, -2, RoundingMode::HalfAwayFromZero), PHP_EOL;
}

先明确 precision 的单位，再检查边界值是否符合产品定义。比如 -2 不是“保留两位”，而是按百位舍入；如果接口字段叫 decimal_places，就不应该把负数直接透传，避免调用者误解。

从旧常量迁移到枚举的落地清单

• 把配置里的整数 mode 映射到明确的 RoundingMode 成员，映射失败立即报错。
• 为 2.5、1.5、-2.5 和退款金额各写一组断言。
• 单独覆盖 precision 为 0、2、-2 的结果，不把小数位数和舍入方向混在一个字段里。
• 金额优先使用整数分或 BCMath；浮点结果只在边界可接受时进入展示层。
• 跨 PHP 8.3/8.4 的库保留旧常量分支，PHP 8.4 专属枚举放在版本能力检测之后。

这里别急着全局替换常量。先把旧结果保存成回归基线，再挑出业务真正需要的方向模式；一旦出现结果变化，能说清是规则升级还是浮点误差，排查会快很多。

常见问题

RoundingMode 是 PHP 8.4 才有的吗？

是。它在 PHP 8.4 中作为枚举提供，用于 round()，也可用于相关 BCMath 舍入接口。

旧的 PHP_ROUND_HALF_UP 还能用吗？

兼容代码仍可使用旧常量，但新代码更适合直接写枚举成员，避免整数或常量名无法表达方向的歧义。

round() 传错 mode 会怎样？

PHP 8.4 会抛出 ValueError。配置驱动的 mode 应在启动或测试阶段尽早验证，不要等订单结算时才暴露。

金额一定要用 RoundingMode 吗？

不一定。金额应先遵守业务精度和单位规则；RoundingMode 只负责把舍入方向写清，不能替代整数分或高精度计算。

把舍入规则当成接口契约

PHP 8.4 的 RoundingMode 让舍入方向终于能直接读懂，但它也把过去隐藏的默认行为暴露出来。升级验收围绕“输入、精度、方向、结果”四项建立用例，再决定是否切换到枚举；这样即使未来更换 PHP 小版本，金额和报表的变化也有可追踪的依据。