PHP中round()必须显式指定精度和舍入模式，因浮点误差易致1.005四舍五入为1.00；金融场景应统一用BCMath运算、DECIMAL存储、字符串传输与number_format输出。
PHP端用round()必须显式指定精度和模式
前端JavaScript的Math.round()对.5的处理是“四舍五入”，但PHP的round()默认使用PHP_ROUND_HALF_UP，表面一致，实际在浮点表示误差下容易翻车。比如1.005在PHP中可能被存为1.0049999999999999，round($x, 2)结果变成1.00而非预期的1.01。
解决方法不是依赖默认行为：
- 所有涉及金额/精度控制的
round()调用，必须写全三个参数：round($value, $precision, PHP_ROUND_HALF_UP) - 若需与JS严格对齐（尤其金融场景），先用
number_format($value, $precision, '.', '')转字符串再转回float，规避二进制浮点误差 - 避免直接对未格式化的数据库浮点字段做
round()，应先用bcadd($val, '0', $scale)做高精度截断
前后端都用字符串传小数，绕过浮点解析差异
JSON里1.23和1.230在PHPjson_decode()后都是float，精度已丢失；而前端parseFloat('1.230')也会抹掉末尾零。这不是bug，是IEEE 754的固有限制。
真正可控的方式是约定传输格式：
立即学习“PHP免费学习笔记（深入）”；
- 后端输出小数时，统一用
number_format($val, 2, '.', '')转成固定两位字符串，如'12.30' - 前端接收后不走
parseFloat()，直接用parseFloat(val + '.00')或正则提取数字部分，再按需补零 - 提交时，前端也发字符串（如
{ "price": "99.99" }），PHP端用floatval()或bcadd($str, '0', 2)转内部计算值
MySQL存储用DECIMAL，别用FLOAT或DOUBLE
如果数据库字段是FLOAT(10,2)，插入12.35可能存成12.3499999999999996——PHP读出来再round()就不可控了。
必须检查并修正表结构：
- 金额、百分比、配置精度值等，字段类型强制为
DECIMAL(12,2)（根据业务调整总位数和小数位） - PHP写库前，用
bcadd($input, '0', 2)确保入参已是精确小数字符串 - 查询时，用
SELECT CAST(price AS CHAR) FROM table直接取字符串，避免MySQL隐式转float
统一取整规则要落地到每个环节：输入、计算、存储、输出
只改输出格式没用。一个典型错误链：前端输入'1.235' → PHP用(float)$input转成1.2349999999 → 存DECIMAL自动截断为1.23 → 输出number_format还是'1.23' → 前端以为丢了精度。
关键动作得串起来：
- 前端输入框限制只能输数字+小数点，用
inputmode="decimal"和正则实时校验位数 - PHP接收时跳过
(float)强转，直接用filter_var($input, FILTER_SANITIZE_NUMBER_FLOAT)清理后保留字符串 - 所有中间计算用
bcmul()、bcadd()等BC函数，不碰原生float - 最终输出前，用
number_format($val, 2, '.', '')兜底，且该值必须来自BC运算结果，而非中间float变量
最易被忽略的是「输入即字符串」这一步——很多人以为接个POST参数无所谓，其实从第一个(float)开始，精度就已经不可逆地污染了。
