改一个PHP变量名，站调刷新页面，试工白屏。站调再改回去，试工好了。站调你盯着屏幕想骂人——错误日志里什么都没有，试工`display_errors` 开着，站调`error_reporting` 设成了 `E_ALL`，试工但 PHP 就是站调不说话。这种事我遇到过不下二十次，试工每次都在想同一个问题：为什么调试 PHP 这么费劲？站调

答案其实不复杂。PHP 的试工运行模式决定了它的调试体验和 Python、Node.js 完全不是站调一回事。后者跑在常驻进程里，试工你可以挂个 debugger，站调打断点，单步走。PHP 呢？每个请求启动一次，执行完就销毁，生命周期短得像蜉蝣。传统做法只能靠 `var_dump()` 和 `die()` 硬扛，在代码里到处插桩，调完再删掉。这种原始方式到今天还在被大量使用，不是因为它好用，而是因为很多人不知道有更好的选择。

Xdebug：绕不开的核心工具

Xdebug 是 PHP 调试领域最成熟的方案，没有之一。它的工作方式是作为 PHP 扩展加载，通过 DBGp 协议和 IDE 通信。你需要在 `php.ini` 里配好几行参数，设置 `xdebug.mode=debug`，指定监听端口，然后在 VS Code 或 PhpStorm 里启动调试会话。听起来步骤不少，但配好之后，你就能在编辑器里直接打断点、查看变量、单步执行、看调用栈。

我用 PhpStorm + Xdebug 调过一个递归函数导致的栈溢出问题。堆栈面板里一层层展开，直接定位到第 47 层递归时参数传错了。如果靠 `var_dump()`，你得在递归里加计数器和条件判断，改好几轮才能找到。这就是差距。

Xdebug 还有几个不太被提及但很实用的功能。`xdebug.mode=coverage` 可以生成代码覆盖率报告，配合 PHPUnit 用。`xdebug.mode=profile` 能输出性能分析文件，用 KCacheGrind 或 Webgrind 打开，一眼看出哪个函数吃了最多时间。很多人只把它当断点调试器用，其实性能分析这块同样值钱。

不装扩展也能做的事

有些环境不让你装 Xdebug——共享主机、某些 Docker 镜像、客户的生产服务器。这时候得换思路。

PHP 内置的 `error_log()` 比 `var_dump()` 优雅得多。它把信息写进日志文件，不破坏页面输出，不会让 JSON 接口返回一堆 HTML。你可以传一个数组进去，加上 `print_r($data, true)` 作为第二个参数，格式清晰。我在调 REST API 的时候基本都用这个，比往响应里塞调试信息干净。

Composer 生态里有个包叫 `symfony/var-dumper`，它的 `dump()` 函数输出格式比 `var_dump()` 好太多。彩色高亮、折叠结构、类型标注，浏览器里看得很舒服。可以独立安装，不用整个 Symfony 框架。装完之后 `composer require --dev symfony/var-dumper`，然后在代码里 `dump($variable)` 就行。生产环境不会执行，因为 `--dev` 标记让它只存在于开发依赖里。

日志和 APM：生产环境的调试方式

开发环境能打断点，生产环境不行。线上出了问题，你不可能挂个 debugger 等请求过来。这时候靠的是日志和 APM 工具。

Monolog 是 PHP 日志库的事实标准。它能把日志写到文件、Syslog、Slack、Elasticsearch，格式和级别都能精细控制。关键是要在代码里埋好上下文信息——用户 ID、请求参数、执行时间。出问题的时候，这些上下文比错误消息本身更有价值。

APM 方面，Sentry 的 PHP SDK 做得很成熟。它自动捕获异常，记录堆栈，还能追踪性能。我见过一个案例：某个接口偶尔超时，日志里只看到执行时间 3 秒，看不出原因。接了 Sentry 的性能监控之后，发现是 Redis 连接池在并发高的时候排队。这种问题靠 `var_dump()` 永远查不出来。

工具的选择取决于你在哪个阶段。写代码的时候用 Xdebug 打断点，快速验证逻辑。接口调试用 `error_log()` 或 `dump()` 输出中间值。上线之后靠 Monolog 记日志、Sentry 抓异常。三个阶段用三套工具，别指望一个方案通吃。

最后说一个容易被忽略的点：`php.ini` 里把 `display_errors` 设成 `On` 只在开发环境合理。生产环境开着这个，错误信息直接输出到页面，用户看到一堆路径和 SQL 语句，安全问题不说，体验也差。用 `log_errors=On` 配合 `error_log` 指定文件路径，错误进日志，页面保持干净。

(责任编辑：综合)