必须同时关闭 display_errors 和 error_reporting 并检查框架、Web 服务器及 CDN 配置，否则错误仍可能通过日志、响应头、500 页面或调试模式暴露敏感信息。
display_errors 关闭后仍报错暴露敏感信息？先查 error_reporting 级别
关闭 display_errors 只是不让错误显示在页面上，但若 error_reporting 仍为 E_ALL 或其他高级别，错误仍会写入日志、甚至被某些中间件（如 Nginx 的 FastCGI 缓存、CDN）意外透出。线上环境必须同时收紧这两项。
-
display_errors = Off（PHP 配置项，建议在php.ini中设，而非ini_set()） -
error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE（生产环境推荐，禁用提示类错误，避免冗余日志） - 确认是否被运行时覆盖：检查入口文件（如
index.php）顶部是否调用了error_reporting(E_ALL)或ini_set('display_errors', '1')
Web 服务器层漏掉错误输出？检查 PHP-FPM 和 Nginx/Apache 配置
即使 PHP 层关闭了显示，若 PHP-FPM 的 catch_workers_output = yes 开启且 stderr 被 Nginx 捕获，或 Apache 的 LogLevel warn 过低，错误仍可能出现在响应体或响应头中（比如 500 页面带堆栈）。
- Nginx：确认
fastcgi_intercept_errors on;已启用，并配好error_page 500 /50x.html - PHP-FPM：检查 pool 配置中
catch_workers_output = no（默认是no，但有些定制镜像会改） - Apache：禁用
php_flag display_errors on，并确保php_admin_flag display_errors off在虚拟主机配置中生效
框架自带调试模式没关？Laravel/ThinkPHP/Django-PHP 类项目常见陷阱
很多 PHP 后台基于框架，它们常自带调试开关，优先级高于 PHP 原生配置。比如 Laravel 的 APP_DEBUG=true 会让 Whoops 错误页强制出现，完全无视 display_errors。
