Hyperf接口无返回的根本原因是异常被吞没或日志缺失上下文，需通过日志级别调整、correlation_id绑定、状态码反查及异常处理器精准控制来定位问题。
Hyperf 接口无返回（空白响应、500、422 但无 errors 字段等），往往不是代码没执行，而是异常被吞掉、日志没带上关键上下文，导致你根本看不到发生了什么。核心思路是：让每一条日志都能精准归属到某一次请求、某一个协程，再结合响应状态反向定位断点。
确认日志是否真正记录了错误
很多“无返回”本质是异常抛出了，但没进日志——因为默认日志级别可能过滤了 warning 或 error，或异常被全局 handler 捕获后没写日志。
- 打开 runtime/logs/hyperf.log，搜索最近几分钟的
Fatal error、Uncaught、Exception、Undefined variable等关键词 - 检查
config/autoload/logger.php中level是否设为'error'或更低（如'debug'），确保异常至少被记录 - 若用了自定义异常处理器，确认其中调用了
$this->logger->error(...)，而不是只 return 响应
验证日志是否能关联到具体请求
协程环境下，多请求日志混在一起，你看到的“报错”可能属于另一个请求。必须绑定 correlation_id 或 request_id。
- 在中间件或控制器入口处手动注入标识：
\Hyperf\Context\Context::set('correlation_id', $request->getAttribute('request_id') ?? uniqid('req_')); - 在日志打印时显式传入：
$this->logger->info('user login start', ['rid' => \Hyperf\Context\Context::get('correlation_id')]); - 避免用
$_SERVER['REQUEST_ID']—— 协程中它不可靠，会串请求
对照响应状态码反查日志线索
用 curl -I 看 header，状态码就是第一线索：
-
404 → 日志里基本不会有业务错误，重点查路由注册（
#[GetMapping]是否生效、路径末尾斜杠是否多余） -
422 + 空 body 或只有 message → 验证失败但
errors字段丢失，检查exceptions.php中 handler 键名是否与server.php的name完全一致（大小写敏感） -
500 + 空 body → PHP 执行中断，看日志是否有
Fatal error；若日志安静，可能是 OOMKilled 或协程阻塞未超时，需查内存和连接池 - 200 + 空 body → Controller 方法没 return，或 return 了 null/void，或中间件提前终止了响应
检查异常处理器是否“接管过度”
自定义异常处理器如果无差别捕获所有 Throwable，反而会让队列任务、协程内部异常也走 Web 流程，掩盖真实问题。
- 打开
app/Exception/Handler/ExceptionHandler.php，检查shouldReport()方法 - 对异步队列异常明确放行：
if ($throwable instanceof \Hyperf\AsyncQueue\Exception\JobException) { return false; } - 对 ValidationException 等业务异常，确保 handler 内调用
$throwable->validator->errors()->messages()，而非仅first()
