yii2内存溢出（oom）不会抛出php异常，而是被系统直接终止，导致页面空白、日志无记录；因其触发的是php致命错误（e_error），而yii2默认错误处理器不捕获致命错误，故无法进入错误处理流程。
Yii2内存溢出（OOM）本身不会抛出 PHP 异常，而是被系统或 PHP 进程直接终止——所以你根本收不到任何“提示”，页面空白、CLI 进程静默退出、日志里也找不到堆栈。想看到提示，得先让错误浮出来，再让它能被框架捕获和展示。
为什么 memory_limit 超限后不显示错误页面
因为 Allowed memory size of XXX bytes exhausted 是 PHP 致命错误（E_ERROR），而 Yii2 的 errorHandler 默认只接管非致命错误（如 E_WARNING）和异常；致命错误发生时，PHP 已经准备中止脚本，register_shutdown_function 都可能来不及执行（尤其 CLI 下被 OOM killer 杀掉时）。所以不是“没配置好错误页”，是根本没机会进 Yii 的错误处理流程。
强制让 OOM 错误可见的三步操作
这不是优雅方案，是排障刚需：
- 在入口文件
web/index.php最顶部加：ini_set('display_errors', '1'); error_reporting(E_ALL | E_STRICT); - 临时提高内存限制（仅用于定位）：
ini_set('memory_limit', '512M');—— 注意：这不能解决泄漏，只为了把报错打出来 - 确认
YII_DEBUG为true，且未被后续代码覆盖（检查是否有多处define('YII_DEBUG', ...)）
做完这三步，如果真是内存耗尽，你会看到标准 PHP 致命错误页面，含完整错误信息和触发行号。
避免 OOM 后静默失败的关键配置
尤其在 CLI 脚本中，必须主动防御：
- 脚本开头立即设置：
ini_set('memory_limit', '-1');（解除限制）+set_time_limit(0); - 禁用日志 trace：
Yii::getLogger()->traceLevel = 0;（防止debug_backtrace()堆积） - 手动控制日志刷盘：
Yii::getLogger()->flushInterval = 1;（避免$this->messages数组无限增长） - 每批大数据操作后调用：
gc_collect_cycles();（PHP 7.3+ 更有效）
这些不是“让提示更好看”，而是阻止内存在你没察觉时就崩掉——一旦进程被 kill，连 display_errors 都没机会生效。
真正要盯住的不是错误提示，是内存增长点
靠错误提示只能知道“爆了”，但不知道“怎么爆的”。必须用 memory_get_usage(true) 打点监控：
- 在循环开始前记下基准值：
$start = memory_get_usage(true); - 在关键节点（如
ActiveRecord::findAll()后、foreach每 100 次）插入：echo "Step X: ".(memory_get_usage(true) - $start)." bytes\n"; - 重点查
asArray()是否漏写、batchInsert后是否没flush、behaviors()是否带闭包引用
所有“显示提示”的努力，都只是帮你把问题暴露出来；真正的解法藏在内存使用曲线的陡升位置里——那里才是你该删代码、换查询、加 unset 的地方。
