var_dump() 总把页面撑乱是因为它默认直接输出到html流且不转义，应改用error_log()写日志或套并htmlspecialchars；print_r()用于可读调试，var_export()生成可执行php代码；json编码需检查返回值防失败。
var_dump() 为什么总把页面撑乱？
因为 var_dump() 默认直接输出到 HTML 流，不加任何 HTML 转义或容器包裹，浏览器会把它当普通文本渲染，格式错乱、样式崩坏、甚至破坏页面结构。
- 调试时优先用
error_log()写日志：比如error_log(print_r($data, true), 3, '/tmp/debug.log') - 必须前端显示时，套一层
<pre class="brush:php;toolbar:false;"><code></code>：用 <code>echo '<pre class="brush:php;toolbar:false;"><code>' . htmlspecialchars(print_r($data, true)) . '</code></pre>' - 别在循环里狂打
var_dump()—— 它本身有性能开销，且输出内容越多越容易触发缓冲区溢出或超时
print_r() 和 var_export() 差在哪？
print_r() 只为「人眼可读」设计，结果不可执行；var_export() 输出的是合法 PHP 代码，能直接复制粘贴进脚本运行，但对闭包、资源、部分对象会报错或返回 NULL。
- 查数组结构、快速看值 → 用
print_r($arr)（加true参数可捕获字符串） - 想生成可复用的测试数据 → 用
var_export($arr, true)，注意它会把字符串单引号化、自动转义 -
var_export()遇到DateTime对象会输出构造语句，但遇到自定义类实例默认只输出类名和属性（PHP 8.2+ 支持__serialize()影响输出）
JSON 编码失败时怎么安全 fallback？
用 json_encode() 格式化变量最干净，但一旦含中文 GBK 编码、
用 json_encode() 格式化变量最干净，但一旦含中文 GBK 编码、\0 字符、不可序列化对象，就会返回 false，不报错也不提示原因。
false，不报错也不提示原因。
- 永远检查返回值：
$json = json_encode($data); if ($json === false) { error_log('JSON encode failed: ' . json_last_error_msg()); } - 中文乱码？确认输入是 UTF-8：
mb_convert_encoding($data, 'UTF-8', 'auto')或提前过滤非 UTF-8 字节 - 含资源或闭包？先用
array_walk_recursive()清洗，把is_resource()和is_callable()的值替换成字符串标识
Xdebug 的 debug_zval_dump() 真有必要用吗？
它显示引用计数和是否为引用，对排查内存泄漏或意外修改有用，但日常开发基本用不上——99% 的变量问题靠 var_dump() + 类型判断就能定位。
立即学习“PHP免费学习笔记（深入）”；
- 只有当你怀疑变量被意外共享、或
unset()后内存没释放时，才打开 Xdebug 用debug_zval_dump($var) - 注意它不递归处理数组/对象深层结构，只看顶层 zval；而且开启后性能明显下降，切勿留在生产环境
- PHP 8.0+ 中，
debug_zval_dump()对某些内部对象（如PDOStatement）可能崩溃，优先用var_dump()+gettype()+is_object()组合判断
var_dump() 在 CLI 和 Web 下行为不同，而 json_encode() 对编码敏感又不报详细错误。多一行 if (json_last_error() !== JSON_ERROR_NONE) 检查，比反复刷新页面猜原因快得多。 
