Hyperf 应用中启动阶段、协程异常或Swoole回调里的致命错误常不输出到控制台或业务日志，需通过runtime/logs/swoole.log定位；应确认日志路径权限、swoole.log配置启用，并结合tail -f实时观察，辅以PHP错误日志和协程异常捕获增强排查。
Hyperf 应用中某些错误（比如启动阶段、协程异常、Swoole 事件回调里的致命错误）可能不会直接输出到控制台，也难以在常规日志中捕获。这时，查看 runtime 日志是定位“不显示的错误”的关键手段，尤其当请求无响应、服务静默崩溃或日志空白时。
确认 runtime 日志路径和启用状态
Hyperf 默认将运行时日志（如 Swoole 错误、PHP 致命错误、协程调度异常等）写入 runtime/logs/swoole.log（非应用业务日志）。需确保：
- 项目已正确生成
runtime/目录且 Web 服务器/Swoole 进程有写入权限 -
config/autoload/server.php中'swoole' => ['log_file' => ...]配置未被注释或覆盖（默认即启用） - 若使用 Docker 或 systemd，检查容器卷挂载或服务用户是否限制了日志路径访问
主动触发并观察 swoole.log 的实时输出
很多隐藏错误只在特定时机（如 Worker 启动、Task 进程 fork、定时器回调）发生。建议：
- 停止服务：
php bin/hyperf.php start --stop - 清空旧日志：
rm runtime/logs/swoole.log - 带前台模式启动并实时跟踪：
php bin/hyperf.php start && tail -f runtime/logs/swoole.log - 复现问题操作（如发起一次请求、触发一个命令、等待定时任务执行），观察
swoole.log是否出现FATAL ERROR、Segmentation fault、coroutine is dead、call_user_func_array(): Argument #1等关键词
补充：开启 PHP 致命错误捕获与协程异常追踪
部分错误（如未捕获的协程内异常、exit() 调用、扩展级崩溃）仍可能绕过 swoole.log。可临时增强排查能力：
- 在
bin/hyperf.php开头添加：ini_set('log_errors', '1'); ini_set('error_log', __DIR__ . '/../runtime/logs/php_error.log'); - 在
config/autoload/exceptions.php中确保ExceptionHandler已注册，并检查Hyperf\ExceptionHandler\LoggerExceptionHandler是否生效 - 对高风险协程逻辑加
try/catch (Throwable $e)并显式logger()->error(...)，避免异常被协程调度器吞掉
常见静默失败场景对照参考
以下错误通常不会出现在 app.log，但大概率留在 swoole.log 中：
-
PHP Fatal error: Cannot declare class Xxx, because the name is already in use—— 类重复加载（常因 Composer 自动加载 + 手动 require 混用） -
WARNING swManager_check_exit_status: worker#0 abnormal exit, status=0, signal=11—— 段错误（常见于扩展冲突、内存越界、xdebug 与 Swoole 不兼容） -
ERROR swCoro_Close: coroutine#123 has been closed—— 协程已结束却还试图 resume 或 defer 执行 -
WARNING swSignalfd_onSignal: signal[17] callback is null—— 信号处理异常（多见于非标准进程管理方式）
