foreach遍历大数组爆内存的根源是ThinkPHP全量加载查询结果，cursor()可改用生成器按需获取。它返回PDOStatement游标，每次仅fetch一行，避免内存溢出，但不支持count()等操作且存在驱动兼容性问题。

为什么 foreach 遍历大数组会爆内存？ ThinkPHP 默认把查询结果全量加载进 PHP 内存，哪怕你只用 foreach 逐条处理。数据库查出 10 万条记录，每条平均占 2KB，光数据就吃掉 200MB —— 这还没算框架 ORM 的对象封装开销。PHP 的 memory_limit 很容易被顶穿，报错通常是：Fatal error: Allowed memory size of XXX bytes exhausted。

• 真正的问题不在循环本身，而在「一次性取回全部数据」这个动作
• ThinkPHP 的 select()、get()、all() 都是全量加载，无论后续怎么遍历
• 即使加了 limit(1000)，如果没配合分页或游标，还是可能因累计处理而溢出

用 yield 改写查询：从「全量加载」到「按需吐出」 ThinkPHP 6+ 原生支持生成器式查询，核心是把 select() 换成 cursor()，再配合 yield 封装成生成器函数。它不把结果集塞进数组，而是让 PDO 保持游标，每次 foreach 到下一条时才 fetch 一行。

function bigDataIterator()
{
    foreach ((new User())->where('status', 1)->cursor() as $row) {
        yield $row;
    }
}
<p>foreach (bigDataIterator() as $user) {
// 处理单条 $user，内存始终只留这一行
}

• cursor() 返回的是 PDOStatement 游标对象，不是数组，不触发自动 fetchAll
• 必须确保数据库连接未关闭，且不能在事务中调用（部分驱动不支持游标 + 事务嵌套）
• 不支持 count()、toArray() 等依赖完整结果集的操作，调了就失效

cursor() 的兼容性坑点 不是所有数据库驱动都稳。MySQLi 和 PDO MySQL 大部分情况 OK，但 PDO SQLite 或 SQL Server 可能直接抛异常：SQLSTATE[HYC00]: Optional feature not implemented。

• ThinkPHP 会尝试 fallback 到普通查询，但不会警告，悄无声息变回吃内存模式
• 若用读写分离，cursor() 默认走读库，但某些中间件（如慢日志记录）可能强制转为写库查询，导致失败
• 字段别名、JSON 类型字段在部分旧版驱动里解析异常，建议显式指定 field(['id','name','extra']) 避免通配符

替代方案：手动分块 + chunk() 的边界注意 如果生成器不可用（比如老版本 TP5.1），可用 chunk() 分批，但它本质仍是多次全量查询：

(new User())->where('status', 1)->chunk(500, function ($users) {
    foreach ($users as $user) {
        // $users 是 500 条的数组，内存峰值取决于 chunk size
    }
});

• chunk() 底层靠主键自增 ID 分页，若数据有删改，可能漏行或重复
• 每次分块都会重新建立查询、执行、fetch，IO 和 CPU 开销比 cursor() 高
• 设置 chunk(1) 并不能等价于生成器，反而更慢，还多一倍查询次数

生成器不是银弹——它要求你彻底放弃「先拿全部再处理」的直觉，也意味着无法回溯、无法统计总数、无法随机访问。这些限制一旦忽略，后面 debug 花的时间远超省下的内存。