PHP调试首选var_dump()配合die()快速定位HTML页面逻辑断点，接口场景则用error_log(print_r($data, true), 3, '/tmp/php-debug.log')安全记录；必须启用xdebug.mode=debug并配置pathMappings才能实现IDE单步断点；debug_backtrace()可追溯调用链，但需加DEBUG_BACKTRACE_IGNORE_ARGS防敏感信息泄露；排查“代码已改却无效”须先禁用OPcache、框架配置缓存及浏览器缓存。
用 var_dump() 和 error_log() 快速定位逻辑断点
PHP 没有像 JS 那样开箱即用的交互式调试器，日常排查逻辑分支、变量状态时，var_dump() 是最直接的选择。但它会中断页面渲染、格式混乱，尤其在 AJAX 或 JSON 接口里容易导致解析失败。
更稳妥的做法是组合使用：
-
var_dump()仅用于开发环境下的 HTML 页面调试，加die()强制终止后续执行，避免干扰 - 生产或接口场景一律用
error_log(print_r($data, true), 3, '/tmp/php-debug.log')写入文件，不暴露数据也不影响响应 - 别直接
echo json_encode($var)调试返回值——它可能破坏原有 JSON 结构，导致前端解析报错SyntaxError: Unexpected token
启用 xdebug.mode=debug 并配合 IDE 单步执行
本地真实断点调试必须靠 Xdebug，但 PHP 8.0+ 默认不启用调试模式，只开 display_errors=On 没用。关键不是装插件，而是确认运行时模式生效：
- 检查
php -i | grep xdebug.mode输出是否含debug（不是off或develop） - 确保
xdebug.start_with_request=yes，否则要手动加?XDEBUG_SESSION_START=1触发 - VS Code 需安装 PHP Debug 扩展，并在
launch.json中设"pathMappings"映射容器内路径（Docker 环境常见坑） - 断点打在
if条件前比打在花括号里更可靠——PHP 有时跳过空行或注释后的断点
用 debug_backtrace() 追查函数调用链异常
当某个变量在某处突然变成 null 或类型错误，又不确定谁改了它，var_dump() 太盲目。这时 debug_backtrace() 能快速列出“谁调用了谁”：
立即学习“PHP免费学习笔记（深入）”；
error_log(print_r(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), true), 3, '/tmp/trace.log');
重点关注 function、file 和 line 字段。常见误用：
- 在魔术方法（如
__get）里调用它，会因递归触发更多调用，日志爆炸 - 没加
DEBUG_BACKTRACE_IGNORE_ARGS，导致敏感参数（密码、token）被完整写入日志 - 误以为它能追踪变量赋值历史——它只记录调用栈，不记录内存变更
绕过缓存和 opcode 导致的“代码已改但行为不变”假象
改完逻辑却没生效？大概率不是代码问题，而是缓存层干扰：
- CLI 下运行
php -d opcache.enable=0 script.php临时禁用 OPcache，排除字节码缓存影响 - Web 环境中，
opcache_reset()只对当前请求生效，需在脚本开头显式调用（且确保opcache.enable_cli=1） - 某些框架（如 Laravel）自带配置缓存，改完
config/文件后要执行php artisan config:clear，否则config('app.debug')始终读旧值 - 浏览器缓存 304 响应也会掩盖 PHP 层改动，调试时用无痕窗口或禁用缓存（DevTools → Network → Disable cache）
真正难缠的逻辑 bug 往往卡在“你以为在执行新代码，其实跑的是缓存版本”——先确认代码确实被重载，再查逻辑。
