浮点数比较不能直接用==或===，因二进制精度限制导致0.1+0.2≠0.3（实际为0.30000000000000004），应使用abs($a – $b)
php浮点数比较为什么总是出错
直接用
==或===比较两个浮点数，大概率会得到意外结果。这不是 PHP 的 bug，而是二进制浮点表示的固有限制——比如0.1 + 0.2在 PHP 里不等于0.3，实际是0.30000000000000004。
- 用
abs($a - $b) 替代相等判断，<code>$epsilon通常取1e-10或根据业务精度调整（如金额用1e-2）- 避免在循环条件中依赖浮点递增，比如
for ($i = 0.0; $i != 1.0; $i += 0.1)可能无限循环- 对用户输入或 jsON 解析来的数字，用
Floatval()显式转换，别依赖隐式转换——它可能受 locale 影响（如逗号小数点）json_encode() 后浮点数变整数或科学计数法
PHP 默认把“看起来像整数”的浮点数（如
5.0、100.0）转成 JSON 整数，而大数值（如1e18）可能被输出为科学计数法字符串，前端 JS 解析后精度丢失。
- 用
JSON_PRESERVE_ZERO_FRACTION选项强制保留小数部分：json_encode(5.0, JSON_PRESERVE_ZERO_FRACTION)→"5.0"- 对高精度场景（如金融），统一用字符串传浮点值，后端用
String类型接收，再用bcadd()等函数运算- 不要依赖
ini_set('serialize_precision', '-1')全局修复——它只影响serialize()和 var_export，不影响json_encode()浮点数转整数时的截断陷阱
(int)、intval()、floor()行为完全不同，且对负数尤其危险。
(int)-3.9得到-3（向零截断），不是向下取整；需要向下取整用floor()，向上用ceil()intval()在 base=10 时和(int)一致；但若传入字符串如intval("9.99")，它会静默丢弃小数部分并转整数，不报错也不警告- 涉及金额计算后取整，优先用
round($val, 0, PHP_ROUND_HALF_UP)，明确指定舍入方式，避免受round()默认模式（四舍六入五成双）影响mysql 存储 PHP 浮点数的精度坑
PHP 的
float是 IEEE 754 双精度，但 MySQL 的FLOAT（单精度）只有约 7 位有效数字，double虽然匹配，仍可能因传输/协议层转换引入误差。立即学习“PHP免费学习笔记（深入）”；
- 写入前用
sprintf('%.15g', $val)格式化再插入，避免 PHP 自动科学计数法输出污染- 字段类型优先选
DECIMAL(10,2)存金额，而不是DOUBLE——后者无法精确表示0.1，DECIMAL是定点数- 从 MySQL 读出的浮点字段，即使 SQL 里写了
select price FROM goods，PHP 接收到的也可能是字符串（取决于 pdo 设置），检查类型用is_string()而非假设是float事情说清了就结束。浮点数问题从来不在“会不会用”，而在“是否意识到它根本不可靠”。
