生产环境要不要开 display_errors
生产环境必须关闭 display_errors，否则敏感信息会直接暴露给终端用户。正确的做法是开启 log_errors 并将错误日志写入服务器文件，这样既能排查问题又能保证安全。
在 PHP 配置中，这两个指令通常成对出现。当 display_errors 设为 Off 时，PHP 引擎会将异常和警告静默处理，不再向浏览器输出任何 HTML 标签或文本。与此同时，log_errors 设为 On 会触发底层记录机制，将错误详情追加到 error_log 指定的路径中。这种组合确保了前端页面的整洁与后端数据的可追溯性。
; ; display_errors ; Default Value: On ; Development Value: On ; Production Value: Off ; display_errors = Off ; ; log_errors ; Default Value: On ; Development Value: On ; Production Value: On ; log_errors = On ; ; error_log ; Default Value: "SAPI-specific error log name" ; Development Value: "SAPI-specific error log name" ; Production Value: "/path/to/error.log" ; error_log = /var/log/php-fpm/www-error.log
上述配置片段展示了标准的 PHP-FPM 环境设置。通过显式指定 error_log 路径，管理员可以集中管理日志，避免分散在各个目录中。如果未指定路径，PHP 可能会使用系统默认的 syslog 或 SAPI 特定的日志位置，这不利于统一监控。
如何权衡 display_errors 与 log_errors 的组合
权衡的核心在于区分开发环境与生产环境的访问权限。在开发阶段，开启 display_errors 能即时反馈代码缺陷；在生产阶段，则完全依赖 log_errors 进行异步分析。
这种权衡并非简单的开关选择，而是基于风险控制的策略。如果仅开启 log_errors 而关闭 display_errors，用户看到的是默认的错误页面或空白页，不会泄露堆栈跟踪、数据库连接字符串或内部文件路径。相反，如果为了调试方便而在生产环境开启 display_errors，攻击者可以利用这些信息进行定向攻击，例如通过报错信息判断 CMS 版本或数据库类型。
; ; error_reporting ; Default Value: E_ALL ; Development Value: E_ALL ; Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT ; error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
除了显示和日志，error_reporting 也是权衡的一部分。在生产环境中，通常会过滤掉 E_DEPRECATED 和 E_STRICT 级别的报告，因为这些通常涉及代码规范而非致命错误。保留 E_ERROR、E_WARNING 和 E_PARSE 足以覆盖绝大多数业务逻辑异常。这种精细化的控制进一步减少了日志噪音，提高了运维效率。
基于 error_log 路径配置的具体问题
当 error_log 路径配置不当或权限不足时，会导致日志丢失，使得生产环境问题无法复现。具体问题是：如果指定的目录不存在或 Web 服务器用户无写入权限，PHP 会静默失败，既不显示错误也不记录日志。
在实际部署中，必须确保 /var/log/php-fpm/ 目录存在且属于 www-data（或对应的 PHP-FPM 用户）所有。可以使用以下命令验证并修复权限：
sudo mkdir -p /var/log/php-fpm sudo chown www-data:www-data /var/log/php-fpm sudo chmod 755 /var/log/php-fpm
此外，还需要检查 PHP-FPM 的池配置文件（如 www.conf），确认 php_admin_value[error_log] 是否覆盖了全局设置。如果池配置中设置了不同的日志路径，全局 php.ini 中的设置将被忽略。这种层级覆盖关系是排查日志缺失问题的关键。通过明确路径权限和配置优先级，可以确保错误信息可靠地落入预期位置。
