PHP调试需用xdebug配合IDE设断点，确认配置、端口及触发参数；生产用error_log()埋点并脱敏；debug_backtrace()查调用链；CLI脚本需显式启用错误报告。
PHP调试不能只靠echo和var_dump，真要定位问题，得用对工具、设对断点、看对上下文。
用xdebug配合IDE打断点是最稳的调试方式
本地开发时，xdebug是PHP调试的事实标准。它不是简单输出变量，而是让执行停在某一行，让你看清调用栈、作用域变量、返回值走向。
- 必须确认
php.ini里启用了xdebug.so（Linux/macOS）或php_xdebug.dll（Windows），且xdebug.mode=debug - IDE（如PhpStorm、VS Code）需安装对应插件，并配置监听端口（默认9003），否则“断点灰色不生效”是常见失败现象
- 浏览器访问时要带
XDEBUG_SESSION_START=1参数，或用官方Xdebug Helper浏览器插件一键触发 - 注意PHP 8.0+版本需用
xdebug 3.x，其配置项名全变了——比如xdebug.remote_enable已废弃，改用xdebug.mode=debug
error_log()比echo更适合生产环境埋点
线上不能回显错误，也不能中断流程，error_log()把信息写进日志文件，不影响用户，还能带上下文时间戳和进程ID。
- 用法：
error_log('user_id: ' . $uid . ', step: ' . $step, 3, '/var/log/php-debug.log'); - 第二个参数
3表示写入文件；4会写入系统日志（syslog），需注意权限 - 别直接拼接敏感数据（如密码、token），先脱敏再记录，避免日志泄露
- 高频调用时注意IO压力，可加条件判断（如仅特定
$uid或$_GET['debug'] === '1'才记录）
debug_backtrace()查清函数是怎么被一路调过来的
当你看到某个变量在某处异常，但不知道谁改了它、谁传错了参数，debug_backtrace()能打印完整调用链，比翻代码快得多。
立即学习“PHP免费学习笔记（深入）”；
- 最简用法：
var_dump(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS));——忽略参数值，只看函数名和文件行号，减少输出体积 - 在框架中间件或全局异常处理器里加这一句，能快速锁定是路由解析错、还是模型构造器提前抛了异常
- 注意它返回的是数组，不要直接
echo，要用print_r或var_export才看得清结构 - 性能敏感路径慎用，每次调用都有开销，临时调试完记得删掉
CLI脚本调试别忘了php -d display_errors=1 -d error_reporting=E_ALL
命令行运行PHP脚本时，默认display_errors常为Off，Notice级错误直接沉默，导致“脚本没反应”却找不到原因。
- 临时启用全部报错：
php -d display_errors=1 -d error_reporting=E_ALL script.php - 想看更详细的错误位置（包括未定义变量、严格模式警告），加上
-d zend.assertions=1（PHP 7.0+） - 如果脚本依赖
$_SERVER变量（如$_SERVER['HTTP_HOST']），CLI下它们不存在，容易触发Notice——这时要主动初始化或用isset()兜底 - 别依赖
ini_set()在脚本开头改配置，CLI模式下部分ini指令是PHP_INI_SYSTEM级，运行时无法修改
真正卡住的bug，往往出在“以为没问题”的地方：比如xdebug版本和PHP不匹配、CLI和Web用的不是同一个php.ini、日志路径没写权限、或者debug_backtrace()返回的file字段指向了框架生成的临时文件而非你写的源码……这些细节不核对清楚，调试就变成猜谜。
