调试php应直接动手解决问题而非先学理论：用var_dump()查类型结构，print_r()配防html解析，xdebug需正确配置mode和触发参数，生产环境用error_log()加条件开关并注意权限与路径。
var_dump()；页面空白？查 error_log；逻辑绕晕了？配好 Xdebug 进 IDE 单步走。方法选错，花三小时不如别人三分钟定位。
var_dump() 和 print_r() 怎么用才不翻车
它们不是“随便插一句就完事”的工具，而是有明确使用边界的快速探针。
- 用
var_dump()查类型和结构：比如var_dump($_POST)能一眼看出是array还是null，有没有被filter_input()截断过 - 用
print_r($var, true)配合<pre class="brush:php;toolbar:false;"></pre>格式化输出，避免浏览器把数组键名当 HTML 标签解析掉 - 别在 header 已发送后调用——会报
Cannot modify header information，改用error_log(print_r($var, true), 3, '/tmp/debug.log') - 线上环境必须删干净，
git grep -n 'var_dump\|print_r'是上线前必跑命令
Xdebug 断点不生效？先看这三件事
90% 的“断点灰色”问题，跟配置无关，跟触发路径有关。
-
xdebug.mode=debug是 PHP 8.0+ 唯一有效的开关，xdebug.remote_enable等旧参数已彻底失效 - 浏览器访问时必须带
?XDEBUG_SESSION_START=1（或用 Xdebug Helper 插件），CLI 脚本则要加php -d xdebug.mode=debug script.php - IDE 监听端口默认是
9003，但如果你本地开了 Docker、Laravel Sail 或其他服务占用了该端口，得在php.ini改成xdebug.client_port=9004并同步更新 IDE 设置
生产环境怎么安全地 debug
不能开 display_errors，不能连 Xdebug，但不代表只能靠猜。
- 用
error_log()写上下文：比如error_log("order_id: {$order_id}, status: {$status}", 3, '/var/log/app-debug.log')，注意先脱敏再拼接 - 加条件开关：只对特定 IP 或带
$_GET['debug'] === 'y'的请求记录详细日志，避免全量刷爆磁盘 - CLI 脚本调试记得显式开报错：
php -d display_errors=1 -d error_reporting=E_ALL script.php，否则Notice级错误直接静默 - 高频接口慎用
debug_backtrace()，它每次调用都有明显性能损耗，临时加完务必删
为什么 error_log() 没写进文件
不是代码错了，大概率是权限或路径没对上。
- 确认
error_log配置项指向的路径存在，且 Web 进程用户（如www-data或apache）有写权限：ls -l /var/log/ | grep php - 不要用相对路径：
error_log('msg', 3, 'debug.log')会写到当前工作目录，而 CLI 和 Web 的工作目录往往不同 - 检查
log_errors = On是否在php.ini中启用，CLI 和 FPM 可能加载不同配置文件，用php --ini和phpinfo()分别确认
var_dump”，而是不知道该在哪一行 dump、该用什么方式触发、该往哪看日志。调试能力是跟着具体错误长出来的，不是读文档读出来的。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
