在 Linux 环境里排查 PHP 报错，很多问题并不是“有没有错误”，而是“错误到底显示到哪里、有没有被安全地记下来”。这篇文章把最常见的两种处理方式拆开讲：一种是修改 php.ini 统一管理，另一种是在脚本中动态设置。看完你可以直接判断，当前场景到底该做全局配置，还是只对单个脚本单独处理。
为什么要先分清“显示错误”和“记录错误”
PHP 的错误处理通常同时涉及两个方向：一是是否把错误直接输出到浏览器，二是是否把错误写入日志文件。这两个配置经常一起出现，但用途并不相同。
display_errors：决定是否直接向页面输出错误信息。log_errors：决定是否把错误写入日志。error_log：指定日志文件路径。error_reporting：决定要报告哪些级别的错误。
如果是在生产环境，通常更关注“记录日志”而不是“把错误显示给访问者”。因为页面直接暴露错误信息，可能会泄露路径、数据库结构等敏感内容。
方案一：修改 php.ini 做全局错误日志配置
如果你希望整台环境里的 PHP 行为保持一致，直接改 php.ini 通常最省事。它的特点是一次配置、全局生效，适合线上服务器、统一部署环境，或者多人共用的项目机器。
先找到 php.ini 文件
常见位置包括：
/etc/php/{php_version}/apache2//etc/php/{php_version}/cli/
其中 {php_version} 需要替换成你实际使用的 PHP 版本号。编辑时可以直接使用：
sudo nano /etc/php/{php_version}/apache2/php.ini重点看这 4 个配置项
打开文件后，先定位下面几项：
error_reporting = E_ALL
display_errors = On
log_errors = Off
error_log = /var/log/php_errors.log它们分别控制错误级别、页面输出、日志开关和日志路径，是最核心的一组参数。
这些参数应该怎么调
error_reporting：控制要报告哪些错误。设为E_ALL表示尽量完整地报告错误；如果要减少提示类信息，可以写成E_ALL & ~E_NOTICE这样的组合。display_errors：控制是否把错误直接显示在浏览器中。生产环境强烈建议设为Off。log_errors：控制是否写日志。一般建议设为On。error_log：指定日志文件位置。除了/var/log/php_errors.log，也可以按项目改成例如/var/log/myapp_errors.log。
如果目标是更适合生产环境的行为，实际思路通常是关闭页面显示、开启文件日志，并保留足够完整的错误级别记录。
修改后别忘了重启 Web 服务器
保存配置后，需要重启服务让设置生效：
sudo service apache2 restart或者：
sudo service nginx restart这一点很容易被忽略。如果改完 php.ini 没看到效果，先检查服务是否已经重启。
方案二：在代码里用 ini_set() 动态设置
如果你不想改动全局环境，或者某个脚本、某个接口需要单独定义错误处理方式，可以直接在代码里覆盖相关配置。最常见的写法如下：
ini_set('display_errors', 0); // 不在浏览器中显示错误
ini_set('log_errors', 1); // 将错误记录到日志文件
ini_set('error_log', '/var/log/php_errors.log'); // 指定日志路径
// 报告所有类型的错误
error_reporting(E_ALL);
// 你的实际代码...这种方式适合什么场景
代码内设置的优势在于灵活，尤其适合下面几类情况：
- 调试某个单独脚本时，临时调整错误输出策略。
- 某些特殊页面需要独立处理，比如 API 接口不希望直接回显错误。
- 不方便改服务器全局配置，但又需要快速观察某段代码的报错行为。
它的生效范围通常只限当前脚本，因此不会影响整个 PHP 运行环境。
它的缺点也很明确
这种方法最大的问题是维护成本。项目脚本一多，就需要反复写相似配置；后续如果日志路径或策略变化，也要逐个调整。对于长期运行的正式项目，这通常不如统一修改 php.ini 来得稳妥。
到底该选哪一种
如果你的目标是统一管理、减少遗漏、让所有 PHP 脚本遵循同一套错误日志规则，优先选择修改 php.ini。如果只是临时调试，或者确实有个别脚本需要特殊处理，再用 ini_set() 会更方便。
可以直接按这个思路判断：
- 面向整台服务器或整套站点：选
php.ini。 - 只影响某个脚本或特殊接口：选
ini_set()。 - 生产环境：通常关闭
display_errors，开启log_errors，并明确指定error_log路径。
从长期维护角度看，默认推荐还是全局配置优先，代码内覆盖作为补充方案使用。
