生产环境必须关闭 display_errors = off 并启用 log_errors = on，指定 error_log 路径，同时配置 web 服务器拦截错误响应，禁用框架调试模式，确保错误不暴露、可追溯、权限安全。
php.ini 中 display_errors 必须设为 Off
生产环境一旦开启 display_errors，任何 PHP 错误（比如 Notice、Warning、Fatal error）都会直接输出到网页上，泄露路径、变量名、数据库结构甚至部分代码逻辑。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
-
display_errors = Off是硬性底线，不能靠ini_set('display_errors', '0')覆盖——某些致命错误（如解析错误）在脚本执行前就触发，ini_set根本没机会运行 - 确认生效：在服务器上执行
php -i | grep display_errors，或写个phpinfo()页面查看，别只改了开发机的配置 - 注意多配置文件场景：如果用了
php-fpm，可能有全局php.ini和 pool 级的www.conf，后者可通过php_admin_flag[display_errors] = off强制锁定，防被脚本绕过
错误必须记录到日志，而不是丢弃
关掉显示不等于关掉错误——它只是把错误从浏览器藏起来。不记录，你就等于在生产环境“盲开”。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 设置
log_errors = On，并明确指定error_log = /var/log/php/error.log（路径需确保 PHP 进程有写权限） - 避免用
syslog或默认空值：空error_log会退化到 SAPI 错误流（如 Apache 的error_log），位置分散难排查；syslog缺少上下文（如请求 URI、IP），定位慢 - 日志等级别别贪大：
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT足够，过度开启E_NOTICE会导致日志爆炸，掩盖真正要处理的问题
Web 服务器层也要堵住错误回显
PHP 层关了，不代表错误不会从 Nginx/Apache 漏出来。尤其当 PHP 崩溃（如段错误）、超时、或 FastCGI 返回异常响应时，Web 服务器可能把原始错误体原样吐给用户。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Nginx：确认
fastcgi_intercept_errors on;已启用，并配好error_page 500 502 503 504 /50x.html，防止后端 PHP 错误变成裸露的 HTML 堆栈 - Apache：检查
ProxyErrorOverride Off（若用 mod_proxy_fcgi），避免反向代理时把 PHP 错误页透传；同时确认php_flag display_errors off在虚拟主机配置里已声明 - 上线前用 curl 测试：故意触发一个
trigger_error('test', E_USER_ERROR)，看响应体是否含错误字串，而不是仅依赖配置检查
框架和 Composer 自动加载也可能暴露细节
现代 PHP 项目常依赖 Laravel、Symfony 等框架，它们自带错误页面（如 Symfony 的 Whoops）。这些页面在生产环境必须彻底禁用，否则堆栈、环境变量、路由参数全亮。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Laravel：确保
APP_DEBUG=false，且.env文件未被 Web 可访问（Nginx/Apache 需禁止访问.env） - Symfony：设
APP_ENV=prod且APP_DEBUG=false，删掉var/cache后重新部署，避免旧缓存保留调试逻辑 - Composer 自动加载失败时（如类不存在），默认会抛出致命错误并显示完整路径。可通过
composer install --no-dev --optimize-autoloader减少错误面，但根本仍是靠前面几层兜底
最易被忽略的是：错误日志文件本身权限和存放位置。/var/log/php/error.log 如果可被 Web 访问（比如放在 /var/www/html/logs/ 下），等于把错误又“展示”了一遍——路径、权限、HTTP 服务配置，三者缺一不可查。
