线上必须关闭display_errors并开启log_errors，确保错误写入日志而非暴露于浏览器；Laravel需设APP_DEBUG=false，Symfony需同时配置APP_ENV=prod与APP_DEBUG=0并清缓存；致命错误须用register_shutdown_function捕获。
PHP框架里怎么关掉错误显示但保留日志
默认开启 display_errors 会导致敏感路径、SQL片段、变量内容直接打到浏览器，线上必须关。但关了不等于不记录——关键是要让错误进日志，而不是消失。
-
display_errors = Off（php.ini 或运行时用ini_set('display_errors', '0')） -
log_errors = On必须同步开启，否则错误既不显示也不落盘 -
error_log = /var/log/php/error.log建议设绝对路径，避免权限或相对路径失效 - Laravel/Symfony 等框架会接管错误处理器，需额外确认是否覆盖了
error_reporting级别
Laravel 中如何禁用调试页面但保留 Whoops 和日志
开 APP_DEBUG=true 会暴露完整堆栈和环境变量，哪怕只在内网也不安全。关掉后默认返回 500 页面，但你可能还想保留本地开发时的友好报错体验。
- 生产环境务必设
APP_DEBUG=false，这是硬性开关，框架级屏蔽所有调试输出 - 日志仍走
storage/logs/laravel.log，只要LOG_LEVEL=error或更细粒度（如debug）就正常写入 - 若想临时看报错但不暴露细节，可改
config/app.php中的'debug' => env('APP_DEBUG', false)，再配合中间件拦截 500 并返回简略提示 - 注意：
Whoops在APP_DEBUG=false下自动禁用，不会残留
Symfony 生产环境错误页为什么还是显示堆栈
常见原因是没切对环境或缓存没清。Symfony 的错误行为由 kernel.environment 和 debug 参数双重控制，光改 .env 不够。
- 确保
APP_ENV=prod且APP_DEBUG=0（注意是数字 0，不是字符串 'false'） - 执行
php bin/console cache:clear --env=prod，否则旧的 debug 模式配置仍生效 - 检查
config/packages/prod/web_profiler.yaml是否误启用了 profiler，它可能带出部分上下文 - Apache/Nginx 若配了
php_flag display_errors on，会覆盖 PHP 层设置，得一并删掉
自定义错误处理器时为什么 set_error_handler 不捕获 E_ERROR
PHP 的致命错误（如 Parse error、Fatal error: Class 'XXX' not found）无法被 set_error_handler 捕获，它们发生在脚本解析或加载阶段，早于运行时。
立即学习“PHP免费学习笔记（深入）”；
-
set_error_handler只处理E_WARNING、E_NOTICE、E_USER_*这类非终止型错误 - 要拦截致命错误，得靠
register_shutdown_function+error_get_last()组合判断 - 框架通常已内置该逻辑（如 Laravel 的
Illuminate\Foundation\Bootstrap\HandleExceptions），自行注册前先确认是否重复接管 - 注意：
error_get_last()在 CLI 模式下可能返回空，因某些 SAPI 不填充该信息
php_flag 或容器中未挂载的 php.ini。 
