Yii2 Console调试核心是--interactive和--verbose：前者强制逐行确认执行流并暴露中间状态，后者提升日志级别至trace并显示完整异常堆栈。
Yii2 Console 应用调试，核心就两条：用 --interactive 看每步执行流，加 --verbose 暴露底层日志和异常细节。不加这两个，等于蒙眼跑命令。
为什么 --interactive 不是“可选”，而是调试刚需
Console 命令默认一气呵成执行，出错时你只看到最终报错或静默失败，根本不知道卡在哪一步、参数传没传对、条件分支走的哪条路。
--interactive 会强制命令逐行暂停，让你确认每一步（比如数据库迁移前是否备份、文件删除前是否列出目标），同时暴露中间状态——比如 $this->confirm() 返回值、$this->prompt() 实际输入内容。
- 只对继承自
yii\console\Controller且显式调用$this->confirm()/$this->select()/$this->prompt()的命令生效 - 不加该参数时，
$this->confirm('xxx')默认按false处理，可能跳过关键逻辑 - 配合
var_dump()或Yii::debug()放在交互点前后，能准确定位变量变化时机
--verbose 开关实际打开的是什么
它不只是“多打几行字”。本质是把 Yii 内部日志级别从 info 提升到 trace，并强制输出未捕获异常的完整堆栈（包括 vendor 里的调用链）。
常见被掩盖的问题靠它直接浮出水面：
-
PHP Warning: Undefined array key "xxx"这类 notice 级错误，在非 verbose 下完全不显示 - 数据库操作失败时，
--verbose会打印出实际执行的 SQL 和绑定参数，而不是只报Integrity constraint violation - 配置加载失败（如
config/console.php中语法错误）会显示具体哪一行 parse error
示例：运行 php yii migrate/up --interactive --verbose，你会看到 migration 类实例化过程、每个 up() 方法的进入/退出、SQL 执行耗时，甚至 AR 查询生成的 WHERE 条件。
组合使用时的典型陷阱
两个参数一起用很强大，但容易忽略环境和配置干扰：
-
--interactive在 CI 环境（如 GitHub Actions）中会卡住，必须加--no-interaction替代；别指望它自动 fallback -
--verbose会输出大量日志到stdout，如果命令本身有echo或print_r()，输出会混在一起难分辨——建议用Yii::info()统一日志渠道 - 某些扩展（如
yiisoft/yii2-redis）的 verbose 日志包含敏感连接信息（host/port），上线前务必检查是否误开启 - 如果命令里手动设置了
Yii::$app->errorHandler->throwExceptions = true，--verbose可能导致未 catch 的异常直接中断流程，而非记录后继续
替代方案：不用参数也能查清问题的关键位置
不是所有场景都能加参数——比如线上 crontab 调用的命令，或者某些封装好的 shell wrapper 屏蔽了参数透传。这时得盯紧三处：
- 查看
runtime/logs/app.log，确保'levels' => ['error', 'warning', 'info', 'trace']已启用（默认不含trace） - 在命令入口加
Yii::setLogger(new \yii\log\Logger());并设置flushInterval = 1，避免日志缓冲导致丢失 - 捕获
SIGTERM或超时退出：用pcntl_signal(SIGTERM, function() { Yii::info('killed by signal'); });定位意外中断点
真正难调的从来不是报错信息，而是“没报错却没干活”——这时候 --interactive 能逼出沉默的分支判断，--verbose 能翻出被吞掉的 warning，少一个都可能多花两小时翻 config。
