var_dump 使用不当会引发乱码、JSON 失效或响应中断；应结合 Xdebug、print_r、日志及环境适配规范调试。
var_dump 用得不对，反而掩盖问题
直接 var_dump($data) 打印变量，常导致页面乱码、JSON 失效或响应中断——尤其在 API 接口或 header 已发送后。它不检查输出上下文，也不自动 escape HTML，遇到数组嵌套深、对象含资源（如 mysqli 连接）时还会报错或卡死。
- 接口开发中，优先用
error_log(print_r($data, true), 3, '/tmp/debug.log')写日志，避免干扰 HTTP 流程 - 调试 HTML 页面时，加一层
echo '<pre class="brush:php;toolbar:false;">'; var_dump($data); echo '</pre>';，否则格式全乱 - 对对象或闭包，
var_dump显示object(stdClass)#1 (0) { }或Closure，看不出内容，此时该换print_r($data, true)+htmlspecialchars()组合 - 生产环境必须删掉所有
var_dump，它可能暴露路径、类结构甚至数据库字段名
Xdebug 配置后没反应？先看 phpinfo() 里有没有 xdebug.loaded
装了 Xdebug 扩展、改了 php.ini，但断点不生效、var_dump 不美化、堆栈不带文件行号——大概率是扩展根本没加载成功，或者版本与 PHP 主版本不匹配（比如 PHP 8.2 装了 Xdebug 3.1）。
- 运行
php --ri xdebug，若提示 “Extension 'xdebug' not present”，说明没启用；若返回一堆配置但enabled => false，检查xdebug.mode是否设为debug,develop - Xdebug 3 必须显式开启模式：
xdebug.mode=debug（远程调试）或xdebug.mode=develop（美化var_dump、增强错误提示） - IDE 断点无效？确认
xdebug.start_with_request=yes（自动启动）或手动加?XDEBUG_SESSION_START=1参数触发 - Chrome 插件（Xdebug Helper）需匹配 IDE key，例如 PhpStorm 默认用
PHPSTORM，插件里要选对应项并启用
dump() 和 debug_zval_dump() 别混用
dump() 是 Laravel 的辅助函数，非 PHP 原生；debug_zval_dump() 是原生函数，但显示引用计数和是否为引用，普通人根本看不懂，还容易误判变量状态。
- 框架项目里写
dump($request->all())没问题，但切到原生 PHP 就会报Call to undefined function dump() -
debug_zval_dump($var)输出类似long(1) refcount(3)，这个 refcount 包含临时 zval，不能用来判断“变量是否被引用”，纯属误导 - 想查变量是否真被引用，用
if ($a === $b && xdebug_debug_zval('a') === xdebug_debug_zval('b'))太重；更简单的是改一个再看另一个变不变 - 日常调试认准
var_dump()（配合 Xdebug）、print_r()（转字符串安全）、json_encode($data, JSON_UNESCAPED_UNICODE)（快速看结构，失败时说明含资源或不可序列化）
CLI 脚本调试时，别依赖浏览器插件
命令行跑的 PHP 脚本（如 cron、artisan 命令），Xdebug 的远程调试需走 TCP 连接，不是靠浏览器 cookie 或 GET 参数触发，配错 host/port 就连不上 IDE。
立即学习“PHP免费学习笔记（深入）”；
- CLI 模式下，
php -i | grep xdebug看到的配置和phpinfo()里的可能不同——CLI 用独立的php.ini，常见于/etc/php/*/cli/php.ini - 必须设
xdebug.client_host=host.docker.internal（Docker 宿主机）或127.0.0.1（本地），且确保xdebug.client_port=9003与 IDE 监听端一致 - 脚本开头加
xdebug_break();可强制断点，比等自动触发更可靠 - 超时脚本卡住？加
set_time_limit(0);并确认xdebug.max_execution_time=0，否则 Xdebug 自己会中断调试连接
