hyperf中协程异常无法前台展示，本质是异常被静默吞掉、响应未正确构造或上下文丢失；需解决异常捕获处理、http响应状态与body返回、日志与前端请求对齐三件事。
Hyperf 中协程异常无法在前台展示，本质不是“没抛出”，而是异常被静默吞掉、响应未正确构造，或上下文丢失导致错误信息无法透出。核心要解决三件事：异常是否被捕获并处理、HTTP 响应状态与 body 是否按预期返回、日志和前端能否对齐同一请求。
确认异常处理器已注册且顺序正确
Hyperf 不会自动捕获所有异常，必须显式配置 handler。若没配或配错位置，异常可能直接穿透到 Swoole 层，最终返回空白或 500 页面，但无具体错误内容。
- 打开 config/autoload/exceptions.php，检查数组中是否有针对业务异常（如
ValidationException、BusinessException）的 handler 条目 - 确保
HttpExceptionHandler（框架内置）排在自定义 handler 之前——否则 404、405 等会被误转成 500，前端收不到标准状态码 - 每个 handler 的
isValid()方法必须精准判断类型，不能笼统返回true，避免宽泛拦截掩盖真实问题
验证响应构造是否包含 errors 字段
常见于表单验证失败却只返回空 JSON（{}），根本原因是 ValidationExceptionHandler 没把 validator 错误结构化输出。
- 检查 server name（如
api）是否与exceptions.php中 handler 键名完全一致、大小写敏感 - 若使用自定义
ValidationExceptionHandler，确保handle()方法中调用了$throwable->validator->errors()->messages()，而不是仅取first()或忽略 errors - 响应体应为：
['code' => 422, 'message' => 'Validation failed', 'errors' => [...]]，而非只有 message
强制注入请求上下文并透出错误标识
协程环境下，异常堆栈容易丢失、日志无法关联请求，导致你看到报错却不知是哪个接口、哪个用户触发的，自然也无法在前台精准展示上下文错误。
- 在中间件或控制器入口，手动设置 correlation_id：
\Hyperf\Context\Context::set('correlation_id', $request->getAttribute('request_id') ?? uniqid('req_')) - 修改 config/autoload/logger.php，启用
LineFormatter的include_stacktraces => true和allow_inline_line_breaks => true - 异常响应中主动带上 request_id：
return $response->withStatus(422)->withBody(...)->withHeader('X-Request-ID', $request->getAttribute('request_id'))
避免协程阻塞导致异常无法及时响应
如果异常发生在被阻塞的协程里（比如用了 sleep()、file_get_contents()），整个 worker 可能卡住，请求超时断连，前端收不到任何响应体，看起来就像“异常没展示”。
- 禁用所有同步 I/O：用
co::sleep()替代sleep()，用Hyperf\HttpClient\Client替代curl_exec() - 检查 vendor 中 SDK 是否支持协程，尤其关注其
connect()或初始化方法是否含stream_socket_client等阻塞调用 - 在关键位置加诊断逻辑，用
Coroutine::listCoroutines()找出长期WAITING的协程并分析堆栈
