最直接有效的PHP调试起点是用好var_dump()和error_reporting()；需在脚本开头启用错误显示并检查php.ini及PHP-FPM配置，避免白屏；var_dump()适合查看变量结构，print_r($data, true)适合日志记录。
PHP 新手想开始调试，最直接有效的起点不是装 Xdebug 或配 IDE，而是先用好 var_dump() 和 error_reporting() —— 它们不需要额外配置，开箱即用，能立刻帮你看到变量值、执行路径和错误位置。
怎么快速定位“页面空白”或“500 错误”
PHP 脚本一出错就白屏，根本看不到提示？默认情况下，PHP 可能关闭了错误显示。必须手动打开：
- 在脚本开头加
error_reporting(E_ALL); ini_set('display_errors', '1');（仅开发环境！） - 检查
php.ini中display_errors = On和error_reporting = E_ALL是否生效（重启 Web 服务后才生效） - 如果用了 Nginx + PHP-FPM，还要确认
php-fpm.conf或 pool 配置里没用php_admin_flag[display_errors] = off覆盖掉
常见现象：加了 echo "here" 没输出 → 实际是 parse error 卡在前面，错误被静默吞掉了。打开错误显示后，第一行报错通常就是真实问题点。
怎么安全地查看变量内容（别再只用 echo）
echo 对数组、对象、null、布尔值完全不友好，容易误判。必须用结构化输出函数：
-
var_dump($data)：显示类型、长度、完整结构，适合调试中间值；加die可中断执行：var_dump($_POST); die; -
print_r($data, true)：返回字符串，适合写入日志；注意第二个参数必须为true才不直接输出 - 避免在 HTML 页面中直接
var_dump()输出复杂结构 → 用highlight_
string(" 更清晰
string(" 更清晰特别注意：var_dump() 会触发对象的 __debugInfo() 方法（如果定义了），可能隐藏真实属性或抛异常，调试时可临时注释该方法。
怎么在不打断流程的情况下记录调试信息
线上环境不能开 display_errors，也不能用 var_dump() 输出到浏览器，得把信息记进文件：
- 用
error_log("msg: " . print_r($var, true), 3, "/tmp/php-debug.log");写入指定文件 - 注意
/tmp/php-debug.log的权限要让 PHP 进程可写（比如 www-data 用户） - 频繁写日志影响性能，调试完务必删掉或注释掉
error_log()调用 - 别用
file_put_contents("log.txt", ... , FILE_APPEND)→ 并发时可能丢内容；error_log()是线程安全的
日志路径建议用绝对路径，相对路径容易因 chdir() 或 CLI 工作目录不同而写错位置。
为什么 var_dump() 看不到 $_SESSION 或 $_COOKIE 的更新？
因为 session 和 cookie 的写入发生在脚本结束时（或调用 session_write_close() 后）。你在中间 var_dump($_SESSION) 看到的是读取进来的旧值，不是刚 $_SESSION['key'] = 'new' 的结果。
- 验证 session 修改是否生效：刷新页面后再
var_dump($_SESSION) - 调试 session 内容，可在修改后立即调用
session_write_close(); session_start();强制重读（仅限调试） - 查看原始 cookie 数据（未解码）：用
$_SERVER['HTTP_COOKIE']，比$_COOKIE更底层、不受 magic_quotes 影响
这个细节很多人卡半天，以为是赋值失败，其实是生命周期理解偏差。
