生产环境必须关闭display_errors=Off，否则Parse error等错误会直接暴露路径、数据库结构等敏感信息；需在php.ini、FPM pool配置等多层统一设Off，并配log_errors=On、error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT，同时检查Nginx fastcgi_intercept_errors及框架调试模式。
生产环境必须关掉 display_errors，否则任何 PHP 错误（包括 Parse error、Undefined variable）都会直接打在网页上，暴露路径、数据库结构、类名甚至部分代码逻辑——这不是“要不要”的问题，是安全底线。
为什么只改 php.ini 里的 display_errors = Off 还不行
PHP 配置有多个生效层，优先级从高到低是：ini_set() > .htaccess（Apache）> user.ini（PHP-FPM）> 全局 php.ini。你改了 php.ini，但 FPM 的 pool 配置（如 www.conf）里写了 php_admin_flag[display_errors] = on，那它就强制为 on，php.ini 白改。
- 检查实际生效值：写个脚本执行
var_dump(ini_get('display_errors'));，看输出是"1"还是""或"0"，别信文件名 - CLI 场景（如 Laravel 队列、crontab 脚本）默认不读 web 段配置，要单独配
php -c /path/to/cli.ini - 用
php --ini和phpinfo()确认 “Loaded Configuration File” 路径，再核对该文件中display_errors和log_errors两个开关
display_errors = Off 和 error_reporting = 0 的区别
error_reporting = 0 不等于“彻底安静”。它只是屏蔽错误级别判断，但如果 display_errors = On，PHP 仍会把 E_WARNING、E_NOTICE 渲染到页面上——这很危险。
- 真正干净的做法是双关卡：
display_errors = Off（强制不输出） +error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT（保留关键错误，过滤过时提示） -
error_reporting(0)在代码里调用，无法屏蔽解析错误（如语法错、require找不到文件），这类错误只受 php.ini 级别控制 - 线上建议设
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED，避免日志被无关信息刷爆，又不漏掉E_ERROR和E_WARNING
Nginx + PHP-FPM 下的隐藏陷阱
Nginx 默认把 PHP 的 stderr 当作 500 错误返回；更隐蔽的是，某些框架（如旧版 ThinkPHP）会在异常处理里强行 echo 错误，绕过 display_errors 控制。
- 确认 Nginx 配置中
fastcgi_intercept_errors on;已启用，并配好error_page 500 502 503 504 /50x.html - 检查
catch_errors和error_page是否兜底，避免裸错进前端 - 在入口文件（如
index.php）开头加ini_set('display_errors', '0');，作为最后一道保险——但它对解析错误无效 - 上线前用
curl测试：故意触发trigger_error('test', E_USER_ERROR)，看响应体是否含错误字串，而不是仅依赖配置检查
log_errors 必须开，且 error_log 路径要可控
关掉显示不等于关掉错误——它只是把错误从浏览器藏起来。不记录，你就等于在生产环境“盲开”。
- 必须设
log_errors = On，并明确指定error_log = /var/log/php/error.log（路径需确保 PHP 进程有写权限） - 避免用空
error_log值：会退化到 SAPI 错误流（如 Apache 的error_log），位置分散难排查 - PHP 8.5 默认会在错误日志里注入请求 ID、参数快照（脱敏后）、调用栈行号范围——如果
error_log权限不对或路径不可写，这些增强信息就全丢了 - 框架层（如 Laravel 的
APP_DEBUG、ThinkPHP 的APP_DEBUG）也得关，否则它们的调试页会覆盖 PHP 层设置
最易被忽略的一点：display_errors = Off 对 Parse error 有效，但如果你在入口文件顶部之前就写了语法错误（比如 index.php 第一行少了个 ;），PHP 根本不会加载到你的 ini_set，错误照样会暴露——所以 php.ini 级别控制永远是第一道、也是唯一可靠的防线。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
