根本原因是locale设置不同导致浮点数格式化行为分化：Windows与Linux默认locale的小数点/千位符及舍入策略不同，展示层应使用NumberFormatter或显式参数，计算层须用bc函数或整数单位避免float不确定性。
PHP 保存小数时在 Windows 和 Linux 上表现不一致，根本原因不是 PHP 版本或配置差异，而是 locale 设置不同导致的浮点数格式化行为分化——尤其体现在 number_format()、sprintf()、printf() 等函数中，以及隐式字符串转换时的小数点/千位分隔符处理。
为什么 number_format(123.456, 2) 在 Windows 显示 “123,46” 而 Linux 是 “123.46”
因为 number_format() 默认使用当前 locale 的小数点和千位分隔符。Windows 中常见 locale（如 Chinese_China.936 或 English_United States.1252）默认用逗号作千位分隔符、句点作小数点；但某些中文 locale（如 Chinese_China）在旧版 CRT 下可能将小数点渲染为顿号或逗号，而 Linux（如 zh_CN.UTF-8）严格遵循 POSIX，小数点恒为 .。
-
number_format()第 3–4 个参数可显式指定小数点和千位符，例如：number_format(123.456, 2, '.', ',')强制统一输出 - 不要依赖
setlocale(LC_NUMERIC, ...)来“修复”，它影响全局且线程不安全，Web 场景下多请求并发时极易污染 - 若需按本地习惯显示金额，应单独做 i18n 格式化（如使用
NumberFormatter类），而非靠number_format()猜 locale
sprintf('%.2f', 1.235) 在不同系统舍入结果可能不同？
这不是系统差异，而是 IEEE 754 浮点精度 + PHP 内部 printf 实现调用的 C 库舍入策略所致。PHP 自身不控制舍入模式，完全委托给底层 libc：glibc（Linux）默认使用“四舍六入五成双”，而 Windows MSVCRT 多数版本用传统“四舍五入”。
- 验证方式：运行
echo sprintf('%.0f', 2.5);—— Linux 常输出2，Windows 输出3 - 业务关键场景（如计费、财务）绝不能依赖
sprintf或round()的默认行为 - 改用
bcmul()+bcadd()做定点运算，或使用round($val, 2, PHP_ROUND_HALF_UP)显式指定舍入模式
数据库写入前用 (float) 或 floatval() 截断小数，为何有时精度丢失？
PHP 的 float 是双精度 IEEE 754，本身无法精确表示十进制小数（如 0.1 实际存储为近似值）。Windows 与 Linux 对同一浮点字面量的解析可能因编译器/库差异产生微小差别，但更常见的问题是：你在字符串转 float 时已引入误差，再存入数据库（尤其是 DECIMAL 字段）就会放大偏差。
立即学习“PHP免费学习笔记（深入）”；
- 避免用
(float)"1.23"解析用户输入；优先用filter_var($input, FILTER_VALIDATE_FLOAT)+ 字符串校验 - 入库前若字段是
DECIMAL(10,2)，应先用round($val, 2, PHP_ROUND_HALF_UP)归一化，再转字符串插入，而非依赖 MySQL 自动截断 - 读取数据库
DECIMAL值时，PDO 默认返回字符串（启用PDO::ATTR_STRINGIFY_FETCHES = false后才转 float），这点在跨平台部署时极易被忽略
真正麻烦的不是“怎么让两边一样”，而是意识到：locale 影响的是**展示层**，而浮点舍入和精度是**计算层**问题——两者混在一起调试，会浪费大量时间在错误的方向上。最稳妥的做法，是展示用 NumberFormatter 或显式分隔符参数，计算用 bc 函数或整数单位（如“分”代替“元”），彻底绕过 float 的不确定性。
