Yii2容器异常因发生在应用启动极早期而绕过errorHandler，需通过PHP原生错误机制（如php-errors.log、php -l检查）定位；调试时应在index.php开头启用display_errors并设全局异常处理器确保API返回JSON。
服务容器异常（如 InvalidConfigException、UnknownClassException、InvalidCallException）在 Yii2 中默认不显示堆栈，尤其在生产环境会静默转为 500 错误页或空白响应——这不是代码没报错，而是容器初始化阶段的异常被 errorHandler 拦截前就已中断流程。
为什么 YII_DEBUG = true 有时也不显示容器异常
服务容器（yii\di\Container）的配置解析发生在应用启动极早期，早于 errorHandler 组件注册。一旦 config/web.php 或其依赖的配置文件中存在语法错误、类名拼写错误、循环引用或未安装扩展（如 php-redis），PHP 就会在 new yii\web\Application($config) 阶段直接 fatal error，根本不会进入 Yii 的异常处理链。
-
require或include配置文件时抛出的ParseError或TypeError，不会触发errorAction -
Yii::$container->get('xxx')手动调用失败时，若上下文无 try/catch，也会直接中断，且不走errorHandler - 调试模式仅影响后续请求生命周期内的异常捕获，对容器构建失败本身无效
定位容器初始化失败的真实错误
必须绕过 Yii 层，直连 PHP 底层错误机制：
- 在
web/index.php开头（require __DIR__ . '/../vendor/autoload.php';之后、new Application之前）插入：error_reporting(E_ALL);<br>ini_set('display_errors', '1');<br>ini_set('log_errors', '1');<br>ini_set('error_log', __DIR__ . '/../runtime/php-errors.log'); - 检查
runtime/php-errors.log（而非runtime/logs/app.log），这里会记录容器加载 config 时的 ParseError、Class not found、Extension missing 等原始错误 - 运行命令行验证：
php -l config/web.php检查语法；php -r "var_dump(class_exists('yii\redis\Connection'));"确认扩展类可加载 - 若使用
Yii::configure()动态注册组件，把该段代码临时提到index.php最前面，并加try/catch包裹
InvalidConfigException 常见触发点与修复
这类异常虽能被 errorHandler 捕获，但默认视图不展示配置上下文，容易误判：
-
'class' => 'app\components\MyService'中类文件不存在或命名空间错位 → 检查app/components/MyService.php是否存在、是否含namespace app\components; - 数据库组件配置中
'dsn' => 'mysql:host=localhost;dbname=mydb'缺少charset，某些 PDO 版本会抛InvalidConfigException而非连接错误 → 补全为'dsn' => 'mysql:host=localhost;dbname=mydb;charset=utf8mb4' -
'as myBehavior' => ['class' => 'app\behaviors\MyBehavior']行为类构造函数参数未提供 → 改为'as myBehavior' => ['class' => 'app\behaviors\MyBehavior', 'prop' => 'value'] - 在
console.php中复用web.php配置，但混入了'response' => ['class' => 'yii\web\Response']这类 Web 专属组件 → 控制台环境下应剔除或条件加载
API 场景下避免容器异常导致 JSON 响应中断
REST 接口若因容器问题返回 HTML 错误页，前端会解析失败。不能依赖 errorAction，而应在入口强制接管：
- 在
web/index.php中new Application前加全局异常处理器：set_exception_handler(function ($e) {<br> \Yii::$app->response->format = \yii\web\Response::FORMAT_JSON;<br> \Yii::$app->response->statusCode = 500;<br> echo json_encode(['code' => 500, 'message' => $e->getMessage()]);<br> exit(1);<br>}); - 该 handler 会捕获容器构建失败、配置解析异常等所有未 catch 异常，确保 API 响应格式统一
- 注意：此方式会跳过 Yii 日志记录，需手动写日志：
file_put_contents(__DIR__.'/../runtime/container-errors.log', date('c').' '.$e, FILE_APPEND);
容器异常最麻烦的地方在于它发生在框架“还没真正启动”的时刻，所有基于 Yii 生命周期的调试手段（debug toolbar、log 组件、errorAction）都尚未就位。唯一可靠的方式是退回到 PHP 原生错误机制，盯住 php-errors.log 和命令行输出，而不是反复刷新浏览器看那个空白 500 页面。
