display_errors 是控制PHP错误是否直接输出到浏览器的配置项，开发时启用便于调试，但上线后必须关闭以防敏感信息泄露；仅用ini_set('display_errors', '0')可能无效，因错误显示还受error_reporting和Xdebug等影响，需同时设置error_reporting(0)并逐层检查php.ini、.htaccess及运行时配置。
PHP display_errors 是什么，为什么不能只靠 ini_set 关掉
display_errors 控制 PHP 错误是否直接输出到浏览器页面。它在开发时有用，但上线后必须关——否则可能泄露路径、变量名、数据库结构等敏感信息。
很多人以为在脚本开头写 ini_set('display_errors', '0') 就万事大吉，其实不一定生效：如果 PHP 配置中 php.ini 的 display_errors = On 且 error_reporting 不为 0，而当前脚本又没调用 error_reporting(0)，错误仍可能显示。因为 display_errors 只决定“要不要显示”，不控制“报不报错”；真正开关错误触发的是 error_reporting。
关 display_errors 的三个有效层级（优先级从高到低）
PHP 配置生效顺序是：运行时函数 > .htaccess（Apache） > php.ini。关掉要逐层确认，避免某一层残留开启。
-
运行时关（脚本内）：必须同时设两个值才稳妥
ini_set('display_errors', '0');error_reporting(0); -
Web 服务器级（Apache）：在网站根目录
.htaccess加php_flag display_errors offphp_value error_reporting 0 -
全局配置（最彻底）：编辑
php.ini，找到并修改两行：display_errors = Offerror_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED（或直接写0）
改完必须重启 Web 服务（如sudo systemctl restart apache2或sudo service php-fpm restart）
验证 display_errors 确实关了的简单方法
别只信 phpinfo() 页面——它只反映配置值，不反映实际行为。真正验证得看错误是否真的不显示：
立即学习“PHP免费学习笔记（深入）”；
- 在脚本里故意写一行错误，比如
echo $undefined_var; - 访问页面，检查：
- 页面是否空白（无任何 Notice / Warning 输出）
- 查看响应 body 是否含
Notice:、Warning:等字样 - 打开浏览器开发者工具 → Network → 查看 Response，确认没错误文本
- 顺带检查日志是否正常记录（说明错误没消失，只是不显示了）：
log_errors = On和error_log = /var/log/php/error.log应保持启用
常见踩坑点：display_errors 关了但错误还在页面上
这通常不是 display_errors 没关，而是其他机制在“代班显示”：
-
Xdebug 开启了
xdebug.force_display_errors = 1—— 它会绕过display_errors设置，强制输出。检查phpinfo()中 Xdebug 部分，或临时注释掉xdebug.so加载 -
框架或 CMS 自带错误处理器，比如 Laravel 的
APP_DEBUG=true、WordPress 的WP_DEBUG，它们会主动把错误 echo 出来，和 PHP 原生设置无关 -
FPM + Nginx 场景下，Nginx 把 PHP 的 stderr 当作响应体返回了，此时要确认
catch_workers_output = yes在www.conf中未开启，或确保 PHP 错误已重定向到日志而非 stderr
线上环境关 display_errors 不是加一行配置就结束的事，关键得验证“错误既不显示、也不泄露”，而日志是否照常记录才是安全底线。
