PHP小数保存差异：Windows与Linux locale区别详解

根本原因是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 字段）就会放大偏差。

• 避免用 (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 的不确定性。