防截断关键是全程杜绝float介入：从HTTP请求取原始字符串、PHP用bc函数计算、数据库用VARCHAR存储、JSON输出前转字符串、前端校验类型。
PHP 保存小数为字符串防截断，核心不是“怎么转”，而是“在哪转、谁在转、谁在解析”。直接用 (string)$float 或 json_encode() 确实能产出字符串，但多数截断问题其实发生在后续环节——比如 MySQL 插入时字段类型是 DECIMAL 却被 PHP 自动转回 float、或前端 JSON 解析又还原成 Number 导致精度丢失。
MySQL 存储前就该定死字符串格式
如果目标是“完全避免浮点运算介入”，那从 PHP 准备数据那一刻起，就不能让小数以 float 类型参与任何中间处理。尤其注意：number_format() 默认四舍五入、sprintf('%.10f', $x) 可能补零但不解决底层精度污染。
- 用
bcadd('0', $float, $scale)或strval($float)（仅限 PHP 8.0+ 对字面量 float 的可靠转换）获取原始字符串表示 - 数据库字段必须是
VARCHAR或TEXT，绝不能是DECIMAL/FLOAT—— 后者会强制解析再存储，等于白转 - 插入前检查：用
is_float($val) && !is_finite($val)排除 INF/NAN，它们转字符串后无法被安全 round-trip
json_encode() 本身不截断，但前端 JS 会
json_encode() 输出的是符合 JSON 规范的数字字面量（如 123.45678901234567），它不会主动截断。问题出在 JS 解析时——IEEE 754 double 最多精确到 17 位十进制数字，超过部分会被静默舍入。
- 若需完整保留，PHP 必须提前转成字符串：
json_encode(['price' => (string)$price]) - 不要依赖
JSON_PRESERVE_ZERO_FRACTION（它只对整数加.0，不保精度） - 前端收到后，务必用
typeof data.price === 'string'校验，而非直接算术运算
别用 float 做中间容器，哪怕只存一次
这是最隐蔽的坑：你写了 $s = (string)$f; $f = 123.4567890123456789;，看似没问题，但 PHP 解析这个字面量时已按 IEEE 754 存入了近似值——var_dump($f) 显示的只是美化输出，真实值早就失真。
立即学习“PHP免费学习笔记（深入）”；
- 从源头控制：接收参数时就用
$_GET['price'] ?? ''拿原始字符串，而不是floatval($_GET['price']) - 计算类逻辑（如加减乘除）必须用
bcmul()/bcadd()，且所有操作数都保持字符串形态 - var_dump() 或 error_log() 里看到“看起来正确”的小数，不代表它没被截断过
真正防截断的关键，是切断 float 类型在整个数据流中的任何存在机会——从 HTTP 请求头、到 PHP 变量、再到数据库字段和 JSON 输出，只要有一个环节松动，前面所有字符串转换都可能白费。
