PHP Generator 怎样用 yield 逐批读取数据

处理大 CSV 或日志文件时，最容易踩的坑不是 yield 语法，而是把全部记录先装进数组。PHP Generator 的正确用法是：读取组件每次只准备一个批次，yield 交给调用方后暂停；调用方继续迭代时，生成器才从暂停点往下走。这样可以把内存上限绑定到批大小，而不是文件总行数。

官方地址：https://www.php.net/manual/en/language.generators.syntax.php

这篇只解决惰性读取和生成器关闭两个问题，不讨论数据库游标、并行消费或把 Generator 再次收集成完整数组。

先把“读完再处理”改成批次契约

假设请求需要导入一份很大的 CSV。一次性 file() 或 iterator_to_array() 会让输入规模直接变成 PHP 数组规模；而生成器函数被调用时并不会立刻把文件读完，它返回一个可迭代的 Generator，执行到 yield 才交出当前值。

这里的契约可以先写成三句话：每次产出一个数组；数组最多包含 $batchSize 条；产出后保留读取位置，下一次迭代再继续。调用方不需要知道文件句柄和行读取细节，只消费批次。

用 yield 封装一个可复用的读取组件

下面的组件把文件句柄藏在生成器内部。关键点有两个：满批次时先交出数组再清空局部变量；循环结束后如果还有尾批次，也要交出一次。

yield 不会像 return 那样结束整个函数，而是保存局部变量和当前位置。下一次 foreach 请求数据时，执行从上一次 yield 后继续。因此，$batch 的生命周期与“当前批次”一致。

消费端怎样提前停止又释放生成器

批量读取通常不是必须读完整个文件：导入达到上限、发现重复数据，或者请求被业务条件截断，都可能在 foreach 中提前 break。这时要让消费端明确拥有 Generator 的引用，并在结束路径释放它。

如果代码里还有另一个变量保存同一个 Generator，单独 unset($generator) 并不能解除最后一个引用；这类封装应统一由一个作用域管理。若处理批次时抛出异常，外层 finally 仍然是回收读取组件的清晰出口。

四个边界状态决定实现是否可靠

把组件放进业务代码前，至少要按下面的顺序确认边界：

还有一个容易被忽略的取舍：批大小越大，单批处理的函数调用和提交次数可能越少，但单批内存也越高；批大小越小，响应更灵活，却可能增加 I/O 和事务开销。它不是越大越好，而是要匹配单条记录大小、处理逻辑和可接受的提交粒度。

性能检查：只保留真正需要的状态

使用 Generator 后，最重要的检查不是把结果再收集成数组，而是观察消费端是否仍然偷偷累积数据。比如在循环中持续执行 $all[] = $row，就会把惰性读取的收益抵消。更稳妥的做法是让 processOrders() 接受一个批次，处理完就释放局部变量；需要汇总时只保留计数、错误摘要或分页游标。

如果业务确实需要全部结果，再使用数组是明确的选择；不要一边声称流式读取，一边调用 iterator_to_array() 把 Generator 重新装回内存。本文的目标是让输入和处理保持批次化，而不是让 Generator 成为另一种数组语法。

常见问题

Generator 调用后为什么还没有读文件？

包含 yield 的函数调用会返回 Generator，函数体在迭代时才逐步执行。真正取第一批数据通常发生在 foreach 请求第一个值时。

提前 break 后一定要手动调用 close 吗？

常用做法是让 Generator 的最后一个引用离开作用域，并把句柄关闭写在生成器内部的 finally。不要依赖一个不存在于当前 PHP API 中的通用 close() 方法。

为什么不能直接把所有批次放进数组？

那会重新把峰值内存绑定到全量数据。若只是需要统计结果，保留计数和错误摘要即可；若必须随机访问全量数据，再明确承担数组的内存成本。

总结一下：读取组件负责按批次 yield，消费端负责处理和停止，资源清理放在生成器的 finally。先把这三条边界写清楚，PHP Generator 才能真正解决大文件读取的内存问题。