php调试关键在于选对时机、用对工具、看懂线索，核心是快速定位代码异常点；需开启完整错误报告、善用xdebug断点追踪、替换var_dump为tracy/whoops，并结合slowlog与profiler分析真实请求链路。
PHP调试不是堆日志、也不是狂打var_dump()，关键是选对时机、用对工具、看懂线索。核心在于快速定位“代码没按预期走”的那个点。
用好错误报告和日志配置
很多问题其实PHP早已提示，只是被静默吞掉了。确保开发环境开启完整错误提示：
- display_errors = On（php.ini 或 .htaccess 中启用）
- error_reporting = E_ALL（捕获所有警告、通知、错误）
- log_errors = On 并指定 error_log = /path/to/php_error.log，便于追踪线上或 CLI 场景下的异常
注意：生产环境必须关闭 display_errors，但要保留 log_errors，否则等于“失明排障”。
善用 Xdebug 进行断点与变量追踪
Xdebug 是 PHP 调试的事实标准。装好后配合 IDE（如 PhpStorm、VS Code）可实现：
立即学习“PHP免费学习笔记（深入）”；
- 点击行号设断点，F8 单步执行，F7 进入函数，F9 跳到下一个断点
- 鼠标悬停看变量值，或在“Variables”面板中展开查看对象/数组结构
- 使用
xdebug_break()在代码中动态插入断点（适合无法直接编辑行号的场景，如框架中间件）
小技巧：在 CLI 脚本中调试时，加参数 php -dxdebug.mode=debug -dxdebug.start_with_request=yes script.php 可免配 IDE 启动监听。
用 Tracy 或 Whoops 替代原始 var_dump
传统 var_dump($data); die; 效率低、不安全、信息杂乱。推荐轻量替代方案：
-
Tracy：一行
Tracy\Debugger::dump($var)，输出带折叠结构、类型、来源行号的彩色 HTML；支持barDump()悬浮面板，不中断流程 - Whoops：专为错误页面优化，把致命错误、异常变成可搜索、可展开的交互式界面，还能看到上下文代码和请求数据
两者都支持 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 分钟内锁定根因。
