在 Debian 环境里遇到 PHP 报错，最怕的不是错误本身，而是不知道该先看哪里。很多问题并不需要马上改代码，先把错误信息暴露出来，再确认日志和运行配置，往往几分钟就能缩小范围。
这篇文章按实际排查顺序整理了一套更稳妥的方法：先用临时错误显示快速定位当前脚本，再结合 Apache、Nginx 或 PHP-FPM 日志确认上下文，最后检查 php.ini 和 Xdebug 配置。看完后，你可以判断当前问题该走“看日志”还是“进调试器”，也能避开生产环境里最常见的误操作。
先临时打开错误显示，快速确认报错位置
如果你只是想先确认当前脚本到底报了什么错，最直接的办法就是临时开启错误报告。在目标 PHP 文件开头加入下面几行：
error_reporting(E_ALL); // 报告所有错误级别
ini_set('display_errors', 1); // 开启错误显示
ini_set('log_errors', 1); // 同时记录到日志（可选）
ini_set('error_log', '/tmp/php_debug.log'); // 自定义日志路径（可选）这样做的作用很直接：语法错误、警告、致命错误都会尽量显示出来，适合在临时调试时快速定位。
但有一个前提必须记住：生产环境不要长期开启 display_errors。如果它保持为 1，浏览器可能直接暴露路径、变量内容甚至服务端敏感信息。排查结束后，应及时改回 0。
先看哪份日志，取决于你的运行方式
在 Debian 下，PHP 错误日志的位置并不完全固定，它和 Web 服务器、PHP 运行模式直接相关。常见情况有三类：
- Apache + mod_php：通常查看
/var/log/apache2/error.log - Nginx + PHP-FPM：通常查看
/var/log/php-fpm.log或/var/log/php7.x-fpm.log，其中x代表 PHP 版本号 - CLI 模式：错误通常直接输出到终端，或者通过
error_log写入指定文件
排查时可以直接实时追踪日志：
sudo tail -f /var/log/apache2/error.log # Apache
sudo tail -f /var/log/php-fpm.log # PHP-FPM如果你不确定当前实例到底把错误写到了哪里，可以用 phpinfo() 查看 error_log 配置项，这通常比手动猜路径更快。
怎么判断应该先看 Apache 日志还是 PHP-FPM 日志
一个实用原则是：如果请求由 Apache 直接处理，先看 Apache；如果站点是 Nginx 转发给 PHP-FPM，优先看 PHP-FPM。前者更容易看到 Web 层报错，后者更容易捕获 PHP 进程本身的异常、崩溃或配置问题。
定位不到时，继续核对 php.ini 配置
如果错误没有按预期显示，或者日志里根本没内容，下一步通常就是确认 php.ini 是否加载正确、关键参数是否生效。
先找到当前环境实际使用的配置文件：
php --ini # CLI模式
php -i | grep "Loaded Configuration File" # Web模式（需创建info.php文件访问）确认路径后，重点检查以下几个参数：
error_reporting = E_ALL # 报告所有错误
display_errors = Off # 关闭浏览器显示（防止敏感信息泄露）
log_errors = On # 开启日志记录
error_log = /var/log/php_errors.log # 自定义日志路径（需确保目录可写）这里最容易出问题的有两点：
display_errors在测试环境和生产环境的目标并不一样，不要混用error_log指向的目录如果不可写，PHP 即使想记日志也写不进去
修改配置后，记得重启对应服务，否则新配置不会生效：
sudo systemctl restart apache2 # Apache
sudo systemctl restart nginx # Nginx
sudo systemctl restart php7.x-fpm # PHP-FPM（替换为实际版本）简单日志不够用时，再上 Xdebug
当问题已经不是“哪里报错”，而是“为什么会走到这里”，单看日志通常就不够了。这类逻辑错误、调用链混乱、变量状态异常的问题，更适合直接用 Xdebug 进入断点调试。
安装与确认 Xdebug
Debian 下可以直接通过仓库安装：
sudo apt-get install php-xdebug # Debian仓库安装安装后，可以用下面的命令确认扩展是否已经加载：
php -m | grep xdebugphp.ini 中的关键配置项
编辑 php.ini，加入或确认以下配置：
zend_extension=xdebug.so
xdebug.mode = debug # 开启调试模式
xdebug.client_host = 127.0.0.1 # 调试客户端IP（本地为127.0.0.1）
xdebug.client_port = 9003 # 调试端口（默认9003，避免与其它服务冲突）
xdebug.start_with_request = yes # 自动启动调试（或设为"trigger"手动触发）其中 xdebug.so 的实际路径可能因系统和 PHP 版本不同而变化，必要时可结合已加载模块情况确认。
配合 IDE 看调用栈和变量值
配置完成后，可以在 PhpStorm、VSCode 等支持 Xdebug 的 IDE 中设置断点，逐步执行代码，直接查看变量值、函数调用栈和分支路径。对于“日志看不明白但程序结果不对”的问题，这通常是效率最高的方式。
日志里没线索，再补查系统日志
如果 PHP 预期日志里没有信息，不代表系统层面没有报错。进程崩溃、权限不足、依赖缺失、服务启动失败，很多时候会先出现在系统日志里。
可以继续查看：
sudo journalctl -xe # 查看系统实时日志（含服务错误）
sudo tail -f /var/log/syslog # 查看syslog（传统系统日志）这一层尤其适合排查“PHP 明明已经配置了日志，但文件始终没输出”的情况，因为真正的问题可能根本不在 PHP 脚本，而是在服务、权限或底层运行环境。
最后别漏掉这三个高频问题
排查走到后面，很多人会忽略一些最基础但最常见的错误场景。下面三项值得顺手检查：
1. 语法错误
先用命令检查脚本语法：
php -l /path/to/script.php这一步非常适合排查白屏、解析失败、改完文件后立刻报错的情况。
2. 文件权限问题
确认 PHP 脚本及其关联文件具备正确读取权限，例如：
chmod 644 script.php如果日志文件或上传目录权限不对，表面上看像是 PHP 代码异常，实际可能只是进程没有读写权限。
3. 扩展缺失
如果报错信息指向扩展缺失，例如 mysqli，可以直接安装对应扩展：
sudo apt-get install php-mysqli这类问题常出现在新机器部署、PHP 版本切换或最小化安装环境里。
排查顺序建议：先快定位，再深调试
更实用的排查顺序通常是这样的：先临时开启错误显示，快速拿到当前脚本的直接报错；接着查看对应运行模式下的日志，确认是不是配置、权限或服务层问题；如果仍然无法解释程序行为，再用 Xdebug 进入断点调试。
对于 Debian 上的大多数 PHP 报错，这个顺序比一上来全局翻代码更省时间。简单问题靠日志和配置就能定位，复杂问题再交给 Xdebug，效率会高很多。
