线上环境默认不显示报错详情是为防敏感信息泄露，需通过APP_ENV=production、DEBUG=false控制，并清缓存；错误应记录到hyperf.log，检查logger配置、目录权限及异常处理器白名单日志，禁用模板中直接输出$exception。
线上环境默认不显示报错详情，是为了防止敏感信息泄露，但排查问题时需要临时打开——关键不是“关掉屏蔽”，而是让错误可查、可控、不暴露给用户。
确认 APP_ENV 和 DEBUG 配置是否生效
Hyperf 通过 APP_ENV 和 DEBUG 控制错误展示行为。线上必须设为：
- APP_ENV=production（非 dev 或 test）
- DEBUG=false（或不定义，框架默认为 false）
这两个值需在 .env 中明确声明，且不能被运行时代码覆盖。改完后清空 runtime/container 和 runtime/cache 目录，避免配置缓存未更新。
错误仍不记录？检查日志通道配置
DEBUG=false 时，Hyperf 不会向响应体输出错误堆栈，但应写入日志。若 runtime/logs/hyperf.log 为空或无错误记录，请核对：
- config/autoload/logger.php 中 default 通道是否启用 file handler
- 日志级别是否设为 ERROR 或更低（如
'level' => 'debug'才能捕获异常前的 warning） - 确保 runtime/logs/ 目录存在且 PHP 进程有写权限（尤其用 Supervisor 启动时，注意 user 配置）
需要临时查看某次错误的完整堆栈？用日志+上下文定位
不建议在线上开启 DEBUG=true，更安全的做法是：
- 在全局异常处理器（app/Exception/Handler/ExceptionHandler.php）中，对特定请求 ID 或 IP 做白名单判断，手动将
$throwable->getTraceAsString()写入独立 debug 日志 - 配合 Swoole 的
Co::getUid()或请求头中的 trace-id，在日志中打标，便于关联上下游 - 若用 Prometheus + Grafana，可加埋点统计
exception_count{class="AppException"}，再结合 hyperf_exception_handler_duration_ms 判断是否集中爆发
浏览器仍看到错误页面？检查视图与中间件顺序
即使 DEBUG=false，若自定义了错误页模板（如 resources/views/errors/500.blade.php）且里面写了 {{ $exception->getMessage() }}，就会把错误信息直接渲染出来。
- 线上模板中禁止直接输出
$exception相关变量 - 检查中间件是否误将异常转为 JSON 并返回（如某些 API 统一格式中间件），确保生产环境返回的是泛化提示如
{"code":500,"message":"服务器繁忙"}
