PHP调试关键在于选对时机、用对工具、看懂线索,核心是快速定位代码异常点;需开启完整错误报告、善用Xdebug断点追踪、替换var_dump为Tracy/Whoops,并结合slowlog与profiler分析真实请求链路。
PHP调试不是堆日志、也不是狂打var_dump(),关键是选对时机、用对工具、看懂线索。核心在于快速定位“代码没按预期走”的那个点。
很多问题其实PHP早已提示,只是被静默吞掉了。确保开发环境开启完整错误提示:
注意:生产环境必须关闭 display_errors,但要保留 log_errors,否则等于“失明排障”。
Xdebug 是 PHP 调试的事实标准。装好后配合 IDE(如 PhpStorm、VS Code)可实现:
xdebug_break() 在代码中动态插入断点(适合无法直接编辑行号的场景,如框架中间件)小技巧:在 CLI 脚本中调试时,加参数 php -dxdebug.mode=debug -dxdebug.start_with_request=y 可免配 IDE 启动监听。
es script.php
传统 var_dump($data); die; 效率低、不安全、信息杂乱。推荐轻量替代方案:
Tracy\Debugger::dump($var),输出带折叠结构、类型、来源行号的彩色 HTML;支持 barDump() 悬浮面板,不中断流程两者都支持 Composer 安装,几行代码即可接入,比手写 print_r + exit 高效得多。
用户说“页面卡”,未必是代码逻辑错,可能是慢查询、远程 API 延迟或循环嵌套。这时需要链路视角:
slowlog(PHP-FPM)记录执行超时的脚本路径和耗时microtime(true) 手动打点,或借助 Xdebug's profiler 生成 cachegrind 文件,用 QCacheGrind 分析函数耗时分布mysqli->query("SET profiling = 1") 或使用 Laravel 的 DB::enableQueryLog() 查看实际执行的 SQL 和时间记住:500 错误要看 error_log,响应慢要看 slowlog + profiler,空白页先查 display_errors 是否关闭。
基本上就这些——配置到位、工具搭好、线索分清,大部分 PHP 问题都能在 10 分钟内锁定根因。