PHP yield 读取大量数据为什么能节省内存

批量读取几十万行数据时，最容易踩到的坑不是 foreach，而是先把所有记录装进数组：数据还没有开始处理，内存峰值已经被一次性抬高。PHP 的 yield 能缓解这个问题，因为它把“准备下一条数据”和“消费当前数据”拆开了。生成器每次只交出当前值，暂停在 yield 位置，下一次迭代再继续。

从内存峰值看出大数组的真正问题

假设一个导入任务要处理 100 万条记录。普通函数可能先返回一个大数组，调用方再遍历它。此时每条记录都要在处理开始前进入数组，峰值大致跟数据总量一起增长；记录还可能包含字符串、嵌套数组和对象，实际占用会比文本大小更高。

yield 的思路不同：函数返回一个可迭代的生成器对象，数据在迭代过程中逐条产生。下面的结构图把“数据源”“当前记录”和“消费者”分开，关键是没有一个节点负责保存完整结果集。

yield 为什么能把读取动作推迟

包含 yield 的函数不是立即执行完再返回数组，而是返回内部的 Generator 对象。迭代器每次需要新值时，PHP 才从上次暂停的位置恢复；执行到下一处 yield 后再次暂停。这个“暂停—恢复”关系正是内存差异的来源。

它并不代表数据被缓存到了某个无限大的隐藏数组里。生成器保存的是函数局部状态、当前键和值以及恢复位置。因此，读取结果只能向前推进，不能像数组那样用任意下标跳回去。

把批量读取改成逐条生成

下面用文本文件模拟导入源，每次读取一行并清洗成关联数组。示例重点不是文件格式，而是让记录在消费完成后失去引用；真实项目也可以把文件读取部分换成数据库游标或分页查询。

 $fields[0],
                'amount' => (float) $fields[1],
                'status' => $fields[2],
            ];
        }
    } finally {
        // 即使调用方提前 break，也关闭外部文件资源
        fclose($handle);
    }
}

foreach (readOrders(__DIR__ . '/orders.csv') as $order) {
    // 这里完成一条订单的校验或写入
    if ($order['status'] === 'paid') {
        processPaidOrder($order);
    }
}

这里的 try/finally 很重要：生成器的优势是数据按需到达，但文件句柄仍然属于外部资源，不能把“少占数组内存”误认为“不需要清理资源”。若业务在循环中 break，应让生成器结束并执行清理逻辑；长生命周期任务也要避免把每一条记录继续追加到另一个大数组。

哪些场景下 yield 仍然不够

生成器降低了读取阶段的内存压力，但不会自动优化所有后续逻辑。如果消费者把每条记录复制到结果数组，峰值仍会重新增长；如果需要按 ID 随机取值、反复从头遍历，生成器的前向特性也不合适。另一个常见误判是把 iterator_to_array() 接到生成器后面——这会再次收集完整结果。

可以用三个问题做收尾检查：是否只需要顺序处理？当前记录处理完后是否会被长期引用？数据源句柄、数据库游标或网络响应是否有明确的关闭路径？三个答案都明确时，yield 才能真正对应稳定的内存边界。

常见问题

调用生成器函数时就会读取全部文件吗？

不会。调用通常先得到 Generator 对象，进入 foreach 后才按迭代需求执行函数体。

yield 会让处理速度一定更快吗？

不一定。它主要改善同时驻留数据的规模，逐条读取、解析和函数恢复也可能带来额外开销，速度要按实际数据源测试。

为什么用了 yield 内存仍然持续上涨？

优先检查消费者是否把记录存进数组、缓存或日志集合，也检查闭包、事件监听器和外部资源是否长期持有当前记录。

PHP 官方手册将生成器描述为一种无需提前构造完整数组的迭代方式。把它放在“顺序读取、即时处理、及时释放引用”的边界内，才是解决大批量读取内存问题的关键。