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免费学习笔记（深入）”；
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
- 后端输出小数时，统一用
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)开始，精度就已经不可逆地污染了。
