var_dump显示小数被截断是Xdebug配置所致，非PHP内核行为；需调整xdebug.var_display_max_depth、max_children和关键的max_data（默认512，建议设1024或-1），重启服务后生效。
var_dump 显示小数被截断是因为 xdebug.var_display_max_depth 等限制
默认情况下 var_dump 本身不省略小数，真正动手脚的是 Xdebug —— 它会主动截断浮点数精度、嵌套深度、字符串长度等。你看到的 float(3.1415926535898) 或直接变成 float(3.14159)，大概率是 xdebug.var_display_max_children 和 xdebug.var_display_max_data 在起作用，而非 PHP 内核行为。
-
xdebug.var_display_max_depth控制嵌套层数，设太低时深层 float 可能显示为... -
xdebug.var_display_max_data限制单个变量显示字符数，浮点数转字符串后超长就被砍掉（比如 30 位小数只显示前 16 位） -
xdebug.var_display_max_children影响数组/对象子项数量，间接导致 float 字段被折叠
改 php.ini 或 xdebug.ini 让 var_dump 显示完整小数
找到你的 php.ini 或独立的 xdebug.ini（用 php --ini 确认加载路径），添加或修改以下配置：
xdebug.var_display_max_depth = 10 xdebug.var_display_max_children = 256 xdebug.var_display_max_data = 1024
注意：xdebug.var_display_max_data 是关键——默认常为 512，而一个高精度浮点数如 0.1234567890123456789 转成字符串就占 21 字符，若数组里有几十个，很快触顶被截。设为 1024 或更高可缓解；设为 -1 表示不限（仅限 Xdebug 3.1+，且生产环境慎用）。
- 改完必须重启 Web 服务器（
sudo systemctl restart apache2）或 PHP-FPM（sudo systemctl restart php*-fpm） - 用
php -i | grep xdebug验证配置是否生效 - 如果用 Docker，确保修改的是容器内生效的 ini 文件，不是宿主机的
不想动 xdebug？用 print_r + number_format 临时看小数
当无法修改环境（如共享主机、CI 流水线），可用纯 PHP 方式绕过显示限制：
立即学习“PHP免费学习笔记（深入）”；
$f = 0.1234567890123456789; echo "raw: " . var_export($f, true) . "\n"; // 输出带精度的字面量，如 0.12345678901234568 echo "formatted: " . number_format($f, 17, '.', '') . "\n"; // 强制显示 17 位小数（注意浮点精度上限）
注意：number_format 受 IEEE 754 限制，PHP float 最多精确到约 15–17 位十进制数字，超出部分是无效数字（不是四舍五入问题，是存储精度已丢失）。真要保留任意精度，请换 BCMath 或 GMP，例如 bcadd('0.1234567890123456789', '0', 19)。
Xdebug 4 即将移除这些选项，得提前适配
Xdebug 4（尚未正式发布，但开发分支已明确）将废弃 xdebug.var_display_* 系列配置，转向统一的 xdebug.mode=develop,debug + 新的 xdebug.cli_color=1 等机制。如果你现在依赖这些设置，建议：
- 尽快升级到 Xdebug 3.x 并测试新配置方式
- 避免在日志或自动化脚本中解析
var_dump输出——它本就不是机器可读格式 - 调试高精度数值时，优先用
printf("%.17g", $f)或写入文件再查，比盯着var_dump更可靠
浮点数显示只是表象，背后是精度表示、序列化方式、调试器介入层级三重叠加。改配置能“看见”更多，但看不见的部分——比如 0.1 + 0.2 !== 0.3——还得靠理解二进制浮点本质来应对。
