hyperf调试di容器错误需启用容器级调试日志而非普通日志开关，核心是配置container.php中'debug'=>true、logger.php中定义'di'通道，并启动时加--debug参数，才能输出依赖链路、循环依赖、接口未绑定等详细错误上下文。
Hyperf开启调试日志输出类实例化错误，核心不是打开log开关，而是让DI容器在构建失败时把完整上下文（谁依赖谁、在哪一步卡住、反射哪行代码）写进日志。默认情况下，这类错误会直接抛异常中断启动，不记录中间状态；要看到“为什么A服务无法实例化”，得主动启用容器级调试日志并配合正确日志通道。
启用容器调试日志需改两处配置
Hyperf的DI容器日志默认关闭。要在日志里看到类似“Resolving App\Service\AService → needs App\Service\BService → BService::__construct() requires IAService”的链路追踪，必须：
- 在config/autoload/container.php中设置
'debug' => true（不是logger.php） - 确保config/autoload/logger.php中存在名为
'di'的channel，且handler指向文件或stdout，例如：'di' => [ 'handler' => [ 'class' => Monolog\Handler\StreamHandler::class, 'constructor' => [ 'stream' => BASE_PATH . '/runtime/logs/di.log', ], ], ] - 启动时加
--debug参数：php bin/hyperf.php start --debug，否则容器不会输出详细解析路径
实例化错误常见类型与日志特征
不同错误在di.log里表现不同，可快速定位：
-
循环依赖：日志出现
Circular reference detected: AService → BService → AService，并列出完整调用栈 -
接口未绑定实现：如
Cannot resolve interface App\Contracts\PaymentInterface，后面紧跟已注册的binding列表 -
构造函数参数缺失：显示
Missing required parameter $config for App\Service\PayService::__construct()，并提示该参数未被容器管理 -
类不存在或未自动加载：报
Class "App\Service\XxxService" not found，同时记录autoloader尝试路径
避免日志被吞或看不到的关键点
即使配了di channel，仍可能看不到日志，原因常是：
- runtime/logs目录不可写——检查
chmod -R 755 runtime/logs，尤其Docker环境下挂载权限 - 没定义
'di'这个channel名——容器只往指定channel写，不会fallback到default - 用了
@Value("lazy")但接口没被@Bean注册——日志会写LazyProxy for IAService: no binding found，而非原始错误 - 异常发生在容器初始化前（如注解扫描失败）——这类问题不在di日志里，要去
php bin/hyperf.php start --debug控制台看stderr输出
结合异常堆栈定位真实根因
单纯看di.log有时不够，比如报“Cannot resolve circular reference”，但实际是某个setter注入写了@Inject却没配@Value("lazy")。这时要：
- 打开
config/autoload/logger.php，找到'default'channel，在formatter constructor中设第四个参数为true（即include_stacktraces => true） - 在
config/autoload/exceptions.php中，确保ExceptionHandler的shouldReport()对RuntimeException返回true，让它进日志 - 启动后看
runtime/logs/hyperf.log，搜索Cannot resolve，对照堆栈最顶层的文件行号，精准定位哪个类的哪个构造函数触发了问题
