Yii2内存溢出主因是日志缓冲堆积与ActiveRecord资源未释放；需调小flushInterval、关闭trace、禁用非必要日志，改用PDO原生查询并主动gc回收。
Yii 框架内存溢出不是 PHP 配置调大就能解决的，根本原因往往在框架自身日志堆积、ActiveRecord 缓存、行为（Behavior）绑定或批量操作未释放资源 —— 尤其在 CLI 脚本中跑大数据时，问题会立刻暴露。
Yii2 日志缓冲区导致内存持续增长
默认 Logger::flushInterval 是 1000，意味着每记录 1000 条日志才刷一次盘。脚本循环几万次，$this->messages 数组不断追加，而每个日志还附带 debug_backtrace()（尤其 traceLevel > 0 时），内存直接线性上涨。
- 临时解决：在脚本开头加
Yii::getLogger()->flushInterval = 1;，强制每次 log 都 flush - 长期方案：CLI 环境下关闭 trace，设
'traceLevel' => 0；或直接禁用日志：'enableLogging' => false（仅限非调试阶段） - 注意：改完后要手动
Yii::getLogger()->flush();一次，否则最后一批日志可能丢失
ActiveRecord 查询和模型实例引发隐式内存泄漏
User::findOne() 或 new User() 看似简单，但 Yii2 会在构造时自动挂载 behaviors、事件监听器、属性变更追踪等，这些对象引用不会随 unset($model) 自动清除，尤其当 behavior 里持有闭包或静态引用时。
- 避免在循环内反复 new model：改用原生 PDO 查询 +
array结果，或用createCommand()->queryAll() - 必须用 ActiveRecord 时，显式调用
$model->detachBehaviors();再unset($model) - 检查 model 类是否定义了
behaviors()，特别是TimestampBehavior、BlameableBehavior这类自带状态管理的 behavior
batchInsert / 批量写入后内存不释放
createCommand()->batchInsert()->execute() 执行完，框架内部仍保有大量 SQL 解析上下文、参数绑定、日志缓存等中间对象，且不会自动 gc。
- 执行后立即调用
gc_collect_cycles();强制回收（PHP 7.3+ 更有效） - 拆分 batch 大小，比如从 1000 改为 100，并在每批后加
Yii::getLogger()->flush(); - 极端情况可临时绕过框架：用
Yii::$app->db->pdo->prepare($sql)->execute($params)手写插入
CLI 脚本没报错 ≠ 没内存问题
Web 环境 OOM 会触发 PHP-FPM 的 memory_limit 限制并报错；但 CLI 下若未显式设置 ini_set('memory_limit', '-1')，它其实受系统 ulimit 和 PHP 编译默认值约束，且 OOM 时 Linux OOM killer 直接发 SIGKILL，连 register_shutdown_function 都不执行 —— 表现就是进程静默退出，无日志、无堆栈。
- 所有 CLI 脚本第一行必须加
ini_set('memory_limit', '-1');（开发调试用），上线前再按需设合理值 - 用
memory_get_usage(true)查看真实分配量，而不是memory_get_usage() - 别依赖
unset()清理大数组，要配合gc_disable(); gc_enable();主动触发回收
最常被忽略的一点：Yii2 的日志缓冲机制和 ActiveRecord 的生命周期管理是深度耦合的，单独调大 memory_limit 或清空变量只是掩盖症状。真正稳定的方案，是把“查-插-删”这类高频操作从框架抽象层下沉到 PDO 层，并严格控制每个循环周期内的对象创建数量。
