var_dump 显示变量类型、长度和资源信息，print_r仅显示内容和结构；var_dump能区分null、空字符串等，print_r易误判；var_dump输出HTML实体需加<pre>，print_r需true参数才可捕获字符串。
var_dump 和 print_r 有什么实际区别
看变量结构时，var_dump 显示类型和长度，print_r 只管内容和嵌套关系。调试数组或对象时，var_dump 能一眼看出 null、string(0) 还是空字符串，而 print_r 全显示成空行，容易误判。
常见错误现象：print_r($arr) 输出什么都没，但其实是个 string(0) "" 或 bool(false) —— 这时候必须换 var_dump 才能确认。
-
var_dump会输出 HTML 实体（比如把<变成），在浏览器里看可能被当成标签“消失”，加 <code>echo '<pre>'; var_dump($x); echo '</pre>';更稳妥 -
print_r默认不返回字符串，直接输出；加第二个参数true才能捕获：$str = print_r($x, true) - 对资源类型（如
mysqli连接），var_dump显示resource(#123)，print_r直接不显示内容，等于白看
调试时怎么避免页面崩掉或信息刷屏
PHP 页面一 var_dump 就乱码、布局错乱、甚至报错终止，不是函数有问题，而是输出时机和位置不对。
使用场景：在控制器逻辑中间、模板渲染前、API 返回前临时加调试语句。
立即学习“PHP免费学习笔记（深入）”；
- 别在已发送 HTTP 头后调用（比如 session_start() 后、header() 后、或 echo 过任何内容再
var_dump），会触发Warning: Cannot modify header information - 避免在循环里无条件
var_dump，尤其处理上千条数据时——加个if ($i === 0) { var_dump($item); }看第一个就够了 - 敏感环境（如生产）绝对禁用裸
var_dump，用error_log(print_r($x, true), 3, '/tmp/debug.log')写日志更安全
想格式化输出又不想写太多代码怎么办
原生函数输出太“糙”，缩进靠猜，JSON 风格看着累，但又不想引入 Xdebug 或 Kint 这类依赖。
性能影响很小，但可读性提升明显，关键是用对方式。
- 封装一个轻量函数：
function dd($x) { echo '<pre class="brush:php;toolbar:false;">'; var_dump($x); echo '</pre>'; exit; }，调试完删掉exit就变d()，继续执行 - 如果项目已用 Composer，
composer require symfony/var-dumper后，dump($x)支持折叠、高亮、对象属性过滤，比原生强得多，且默认不exit - 注意：
symfony/var-dumper在 CLI 下自动美化，在 Web 下需确保xdebug.mode=develop或启用html_errors=On，否则退回纯文本
为什么有时候 var_dump 显示 “Recursion” 就停了
不是卡死，是 PHP 检测到变量内部存在循环引用（比如对象 A 的属性指向对象 B，B 又反向指向 A），var_dump 主动中止展开，防止无限递归崩溃。
这在 Laravel 的 Eloquent 模型、ThinkPHP 的关联查询结果里特别常见。
- 这不是 bug，是保护机制。想看具体哪层循环，改用
var_export($x, true)（但只支持数组/标量，对象会报错） - 更实用的办法：用
json_encode($x)看能否转成功，失败说明有不可序列化内容（如资源、闭包），顺便暴露问题点 - 真正要查循环引用，得用
Xdebug的xdebug_debug_zval或断点逐步 inspect，var_dump本身做不到穿透
