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 Options开启）：无需重启，但不适用于 CLI 或 Nginx
php.ini 中怎么设置 error_reporting 和 display_errors
这两个选项要配对使用，否则可能“设了等于没设”。常见组合如下：
- 生产环境（隐藏错误，只记录）：
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICTdisplay_errors = Offlog_errors = Onerror_log = /var/log/php_errors.log -
开发环境（显示所有错误）：
error_reporting = E_ALLdisplay_errors = Onlog_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 请求是否真关掉了错误显示。
