生产环境必须关闭错误显示，因display_errors=off需在php.ini、fpm配置、.htaccess等多层统一设为off，并配合error_reporting=e_all & ~e_deprecated & ~e_strict、log_errors=on及安全日志路径，同时检查cli、nginx fastcgi_intercept_errors及代码中ini_set调用，杜绝任何错误输出。
PHP 生产环境必须关闭错误显示，否则会暴露路径、版本、数据库结构等敏感信息——这不是可选项，是安全底线。
为什么 display_errors = Off 不能只改 php.ini
很多线上问题出在：改了全局 php.ini，但没覆盖到 CLI、FPM 或虚拟主机配置层。PHP 有多个配置生效点，优先级为：运行时 ini_set() > .htaccess（Apache）> user.ini（PHP-FPM）> php.ini。尤其 FPM 场景下，php.ini 里设了 display_errors = Off，但 www.conf 里又写了 php_admin_flag[display_errors] = on，那就白设。
- 检查实际生效值用
var_dump(ini_get('display_errors'));，别信配置文件名 - CLI 脚本（如 Laravel 队列、定时任务）默认不读
php.ini的 web 相关段，要单独配php -c /path/to/cli.ini - 使用
phpinfo()页面时，确认 “Loaded Configuration File” 路径，并核对该文件中display_errors和log_errors两个开关
error_reporting 设成 0 不等于“彻底安静”
设 error_reporting = 0 只是屏蔽错误级别，但若 display_errors = On，PHP 仍会把警告、Notice 渲染到页面上——这很危险。真正干净的做法是双关卡：
-
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT（保留关键错误，过滤过时提示） -
display_errors = Off（强制不输出到浏览器） -
log_errors = On（必须开，否则错误全丢） -
error_log = /var/log/php/error.log（指定日志路径，确保 Web 用户不可访问）
注意：error_reporting(0) 在代码里调用，无法屏蔽解析错误（如语法错、require 找不到文件），这类错误只受 php.ini 级别控制。
FPM + Nginx 下的隐藏陷阱：500 错误不报错，但其实没关干净
Nginx 默认把 PHP 的 stderr 当作 500 错误返回，如果 display_errors = On，哪怕页面没输出，FPM 日志里也会记下完整错误堆栈；更隐蔽的是，某些框架（如旧版 ThinkPHP）会在异常处理里强行 echo 错误，绕过 display_errors 控制。
- 检查
fastcgi_intercept_errors on;是否启用（Nginx 配置），否则 PHP 的 500 会被透传给用户 - 确认
catch_errors和error_page配置是否兜底，避免裸错进前端 - 在入口文件（如
index.php）开头加ini_set('display_errors', '0');，作为最后一道保险 - 用 curl 测试真实响应：
curl -I https://yoursite.com看 Header 是否含X-Powered-By，含则说明仍有信息泄露风险
最常被忽略的一点：开发机和生产机共用同一份部署脚本，而脚本里硬编码了 ini_set('display_errors', '1') ——这种“方便调试”的写法，在上线后就是安全缺口。关报错不是改一个开关，是切断所有可能的输出路径。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
