Hyperf优化Collection内存，Generator更高效

Hyperf中Collection处理大结果集时极易因全量加载模型实例导致内存爆炸，而采用Generator配合cursor()实现流式逐行读取可将内存占用稳定在KB级别；本文深入剖析了Collection爆内存的根本原因、cursor()与chunk()的本质差异及适用边界，并提供了禁用自动装配、原生语句+yield、协程环境下Generator安全使用的完整实践方案，助你彻底告别OOM崩溃，高效应对海量数据遍历、导出与批量处理场景。

Hyperf里用Collection接大结果集为什么爆内存

因为 Collection 是完整对象数组的封装，底层调用 iterator_to_array() 或直接 new ArrayObject，所有模型实例、关系数据、访问器、隐藏字段全被加载进内存。哪怕你只取 id 和 name，Eloquent 默认仍会 hydrate 完整模型——每个模型带属性容器、变更跟踪、关系缓存，10 万条轻松吃掉 80MB+。

常见错误现象：Fatal error: Allowed memory size of 134217728 bytes exhausted；CLI 脚本跑一半卡死；Web 接口返回 500 且日志里没堆栈（已被 OOM killer 杀掉）。

关键点在于：你只是想遍历、导出、统计或批量处理，根本不需要随机访问 $collection->first() 或链式调用 ->filter()->map()。

把 Eloquent 查询结果转成 Generator 的实操步骤

不是“改个返回类型”就行，得从查询源头切断全量加载链路：

• 禁用 Eloquent 的自动模型装配：用 Db::table('users')->select('id', 'name')->cursor() 替代 User::select('id', 'name')->get() —— cursor() 返回的是 Generator，逐行 fetch，不缓存结果集
• 若必须用模型，改写查询为原生语句 + 手动 yield：

  function getUsersCursor(): Generator {
      $stmt = Db::getPdo()->prepare('SELECT id, name FROM users WHERE status = ?');
      $stmt->execute([1]);
      while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
          yield $row; // 不 new User，只交关联数组
      }
  }

• 确保函数声明返回类型为 Generator，否则 PHP 8.2+ 直接报错；别写 iterable，IDE 和静态分析会失去对 yield 流程的感知
• 调用时直接 foreach (getUsersCursor() as $user)，别赋值给变量，也别包 collect()

cursor() 和 chunk() 的本质区别与选型陷阱

cursor() 是游标式流式读取，依赖 PDO 的 PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => false（Hyperf 默认已关缓冲），内存恒定在 KB 级；chunk() 是分页式批量加载，每次仍要拉一批进内存（如 chunk(1000) 就是每批 1000 行对象），10 万条仍会触发 100 次小内存峰值。

容易踩的坑：

• cursor() 不支持 orderBy 外的复杂查询（如子查询、UNION），遇到必须先建物化视图或临时表
• cursor() 在 MySQL 中要求结果集有唯一递增字段（如 id）作游标锚点，否则可能漏数据；若用 created_at，注意精度和重复值
• chunkById() 看似安全，但它内部仍是 limit/offset 模拟，大数据量下 offset 越大越慢，且无法规避单次 chunk 的内存占用

Hyperf 协程环境下 Generator 的注意事项

Generator 本身是同步迭代器，和协程无关——它不挂起 I/O，也不让出 CPU。但在 Hyperf 里混用时，有三个硬约束：

• 别在 yield 函数里调 co::sleep() 或 await 协程函数，会报 Fatal error: Uncaught Error: Cannot use "yield" inside an anonymous function in coroutine context
• Generator 函数内不能 return 值（只能 return; 表示结束），否则抛 Exception: A generator must not return a value
• 如果 Generator 内部需要查 Redis 或调第三方 API，必须拆成两层：先用 cursor() 流式取 ID 列表，再用 Coroutine\Channel 或 Parallel 并发处理，别把 I/O 塞进 yield 逻辑里

最易被忽略的一点：Generator 对象本身不持有数据库连接，但它的迭代过程会持续占用一个 PDOStatement，直到遍历结束或显式 closeCursor()。如果 foreach 中途 break，记得手动释放，否则连接池可能被占满。

今天关于《Hyperf优化Collection内存，Generator更高效》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！