Hyperf 启动错误需确保可见而非静默吞掉：先启用 --debug 开启调试模式，再保证错误输出到终端（禁用重定向），同时确认 CLI 模式下 display_errors=On、error_reporting=E_ALL，并通过 php bin/hyperf.php list 或 var_dump($_ENV) 验证基础配置加载。
Hyperf 启动时想看到更详细的错误信息，关键不是加个 --debug 就完事，而是让错误能真正“冒出来”、不被静默吞掉，并且在合适的位置输出。默认情况下，很多错误（比如注解冲突、配置加载失败、扩展缺失）会卡在启动早期，连日志都写不进文件，终端也只闪一下就退出。
启用 --debug 参数并配合标准输出
启动命令中加上 --debug 是第一步，但它本身不打印日志，只是开启框架内部的调试模式（如显示更详细的异常堆栈、禁用某些缓存）。要让错误可见，必须确保它输出到终端：
- 直接运行：
php bin/hyperf.php start --debug，不要后台运行或重定向到/dev/null - 如果用 Supervisor 管理，
command=中也必须包含--debug，且不能加> /dev/null 2>&1，否则所有输出都会丢掉 -
--debug对 Swoole/ Swow 的启动阶段错误（如端口被占、扩展未加载）无效，这类问题需靠系统层排查
检查 PHP 和扩展报错是否开启
Hyperf 启动前的致命错误（如 Class not found、syntax error）由 PHP 解释器抛出，能否看到取决于 PHP 配置：
- 确认
display_errors = On、error_reporting = E_ALL在当前 CLI 模式 php.ini 中生效（运行php -i | grep -E "(display_errors|error_reporting)"验证） - 若用 Docker 或容器环境，注意 CLI 和 FPM 使用不同 php.ini，调试时务必用
php -v所指的 CLI 配置 - 常见静默失败场景：Swoole 扩展未启用 → 报错
Class 'Swoole\Http\Server' not found，但因display_errors=Off被忽略
捕获启动早期日志到文件
有些错误发生在日志组件初始化之前（如 config/autoload/logger.php 语法错误），此时框架自己的 logger 还没起来。可借助 Supervisor 或 Shell 临时捕获：
- Supervisor 配置中设
stdout_logfile=/var/log/supervisor/myapp-start.log，并确保redirect_stderr=true，这样 PHP 解析期错误也会进该文件 - 手动启动时用
php bin/hyperf.php start --debug 2>&1 | tee /tmp/hyperf-start.log，实时查看+留存 - 特别注意
.env加载失败（如路径错、语法错）会导致后续所有配置为空，错误通常出现在第一行，但容易被滚动刷走
验证配置加载是否成功
很多“没报错却启不动”的情况，其实是配置没加载，而非代码异常。快速验证方式：
- 运行
php bin/hyperf.php list，能列出命令说明 DI 容器和基础配置已通；若报错或无响应，问题在最底层（PHP/Swoole/.env） - 临时在
bin/hyperf.php开头加var_dump($_ENV); exit;，确认环境变量读取正常 - 检查
config/autoload/下关键文件（server.php、dependencies.php、logger.php）是否有语法错误或 require 失败
