var_dump适合查类型和结构细节，print_r适合快速查看键值关系；kint是var_dump的增强视图层；xdebug提供上下文快照而非单点快照；phpdbg适合无扩展命令行调试。
var_dump 和 print_r 什么时候该用哪个？
var_dump 适合查类型和结构细节，比如你怀疑某个变量是 null 还是空字符串、布尔值是不是真被转成了整数；print_r 更适合快速看数组/对象的键值关系，尤其在调试 API 返回数据或表单提交内容时更清爽。
常见错误现象：用 print_r 查 bool(false)，结果只看到空白（默认不显示 false），误以为是空；用 var_dump 打印大数组，页面卡死或输出被截断。
-
var_dump默认会输出类型和长度，支持递归深度控制：var_dump($data, 2)（PHP 8.3+） -
print_r可加第二个参数true返回字符串，方便日志写入：error_log(print_r($data, true)) - 两者都不该出现在生产环境代码里——它们会直接输出到响应体，可能暴露敏感数据或破坏 JSON 格式
Kint 是不是比 var_dump 更值得日常用？
是，但前提是项目已引入 Composer，且你愿意多敲几个字符换来可交互体验。Kint 不是“替代品”，而是 var_dump 的增强视图层：它把嵌套结构折叠起来、支持键盘搜索字段、点击就能复制访问路径（比如 $data['user']['profile']['email']），对调试 Laravel 或 Symfony 的复杂请求对象特别省力。
使用场景：你在处理一个深层嵌套的 $_POST 或 API 响应，想快速定位某个字段却不知道它在哪一层。
立即学习“PHP免费学习笔记（深入）”；
- 必须调用
Kint::dump()或简写d()，不能直接当函数名用 - 默认开启 HTML 输出，如果在 CLI 脚本里用，得先调用
Kint::enabled(false)切回纯文本 - 它会自动检测是否在 AJAX 请求中，避免污染 JSON 响应头——这点比手写
if (php_sapi_name() !== 'cli') { ... }省心
Xdebug 的调试器模式真能代替 var_dump 吗？
能，但不是“代替”，而是升级成另一套工作流。当你需要观察变量随执行流程的变化、判断某段逻辑是否真的走入、或者想看清闭包里的 $this 引用关系时，var_dump 就退场了——Xdebug 提供的是上下文快照，不是单点快照。
容易踩的坑：开了 xdebug.mode=develop,debug 却没配好 xdebug.client_host，结果调试连接超时，IDE 一直等不到请求；或者忘了关 xdebug.start_with_request=yes，导致每次 curl 或 cron 都触发调试连接，拖慢整个系统。
- 断点调试 ≠ 把所有
var_dump换成断点——高频循环里打断点会让调试卡死，这时仍要靠error_log+json_encode记录关键状态 - Xdebug 5.x 开始强制要求
xdebug.mode显式声明，旧配置如xdebug.remote_enable=1已失效，直接忽略不报错，非常隐蔽 - 如果用 Docker，
xdebug.client_host很可能不是127.0.0.1，而是host.docker.internal（Mac/Windows）或宿主机真实 IP（Linux）
PHP 内置的 phpdbg 适合什么人用？
适合不想装扩展、又不愿开 IDE 的命令行党，比如在服务器上临时查一段脚本为什么跑不通。它没有图形界面，但支持设置断点、查看符号表、甚至修改运行时变量值——比纯 var_dump 强，比 Xdebug + IDE 轻。
性能影响很小，因为它是 PHP 自带的 SAPI，不依赖 Zend 扩展机制；但不支持远程调试，也不能和 Web 请求联动——你不能让浏览器访问一个 URL 就自动进 phpdbg，只能手动执行脚本。
- 启动方式简单：
phpdbg -qrr script.php（-qrr表示静默启动并运行） - 断点命令是
b，列出断点用l，继续执行是c，和 GDB 风格一致 - 它无法解析 Composer 自动加载的类，遇到
class not found别慌，不是 bug，是它压根没加载vendor/autoload.php，得手动require进来
调试工具选型这事，本质是权衡“信息粒度”和“介入成本”。var_dump 最低门槛，但信息最糙；Xdebug 最准，但要配通一整条链路；中间态像 Kint 或 phpdbg，往往卡在“用得顺手”和“部署麻烦”的临界点上——别迷信推荐列表，先试一个能在你当前环境 5 分钟内跑起来的。
