PHP错误报告级别必须写入配置文件才能持久生效，仅用error_reporting()或ini_set()仅影响当前脚本；推荐修改php.ini（需重启服务），也可用.htaccess（仅Apache且需AllowOverride开启）；error_reporting与display_errors需配对设置，生产环境应关闭display_errors并开启log_errors，开发环境可开启display_errors；注意CLI与Web环境配置可能不同，须分别验证。

PHP错误报告级别能不能写进配置文件

能，而且必须写进配置文件才能实现持久生效。仅靠 error_reporting() 函数或 ini_set('error_reporting', ...) 只影响当前脚本运行时，重启 PHP 或换脚本就失效。

关键是要区分两个配置位置：

• php.ini（全局生效，推荐）：修改后需重启 Web 服务器（如 Apache/Nginx + PHP-FPM）
• .htaccess（仅 Apache，且 AllowOverride Op

  

  tions 开启）：无需重启，但不适用于 CLI 或 Nginx

php.ini 中怎么设置 error_reporting 和 display_errors

这两个选项要配对使用，否则可能“设了等于没设”。常见组合如下：

• 生产环境（隐藏错误，只记录）：
  error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
log_errors = On
error_log = /var/log/php_errors.log
• 开发环境（显示所有错误）：
  error_reporting = E_ALL
display_errors = On
log_errors = On

注意：display_errors = On 在 CGI/FastCGI 模式下（如多数 Nginx 配置）可能被忽略，此时必须依赖浏览器端是否收到 PHP Notice 响应头——实际仍取决于 SAPI 层行为，不能完全信任。

立即学习“PHP免费学习笔记（深入）”；

为什么改了 php.ini 还不生效

常见原因不是配置写错，而是没找对生效的配置文件，或未触发重载：

• 用 php --ini 查 CLI 使用的 php.ini；用 phpinfo() 页面查 Web SAPI 加载的实际路径
• Nginx + PHP-FPM 场景下，php.ini 通常在 /etc/php/{version}/fpm/php.ini，改完要执行 sudo systemctl reload php{version}-fpm
• Apache 下可能加载了多个 ini 文件（如 conf.d/ 目录下的扩展配置），后面加载的会覆盖前面的同名指令
• display_errors 被 .user.ini 或 ini_set() 运行时覆盖，可用 var_dump(ini_get('display_errors')); 确认最终值

CLI 和 Web 环境的 error_reporting 可能不同

PHP 允许为 CLI 和 Web SAPI 分别指定配置文件（通过 --php-ini 或编译时设定），所以 php -v 显示的 error_reporting 值，和 phpinfo() 里看到的可能完全不同。

验证方式必须分开：

• CLI：运行 php -r "var_dump(error_reporting());"
• Web：新建 test.php，内容为 ，通过浏览器访问

很多线上问题就出在这里——开发者只调通了 CLI 脚本，却没检查 Web 请求是否真关掉了错误显示。