Eloquent 的 cursor() 和 chunkById() 能真正解决大数据内存问题，而 LazyCollection::make(Model::get()) 无效且更耗内存，因 get() 已全量加载数据到内存，惰性包装为时已晚。
直接说结论：Eloquent 的 cursor() 和 chunkById() 是真正能解决大数据内存爆掉的问题的方案，而 LazyCollection::make() 包裹普通查询（比如 get()）毫无意义，反而更耗内存。
为什么 LazyCollection::make($collection) 对 Eloquent 查询无效
很多人误以为把 Model::get() 结果丢进 LazyCollection::make() 就能“变懒”，其实不是。因为 get() 本身已执行 SQL 并把全部结果加载进内存、实例化为 Eloquent 模型数组——此时再套一层 LazyCollection，只是对已有内存对象做延迟迭代，没减少任何内存占用，还多了一层对象开销。
-
Model::get()→ 立即执行查询 + 全量 hydrate + 全部存入 PHP 数组 → 内存峰值由数据量决定 -
LazyCollection::make(Model::get())→ 先干完上面所有事，再包装成 lazy → 内存已爆，包装晚了 - 真正惰性必须从「查询执行阶段」就开始控制，让 PDO 不一次性 fetch 所有行
用 cursor() 实现真正的逐行流式处理
cursor() 是 Laravel 8.29+ 引入的底层惰性方案，它不使用 offset/limit，而是基于数据库游标（通常是主键或唯一有序字段），每次只 fetch 一小批（默认 1000 行），且模型是边读边实例化、用完即释放，内存几乎恒定。
- 要求表有带索引的单调递增字段（如自增
id或created_at），否则会漏数据或重复 - 不能用
orderByRaw()或复杂排序；推荐显式写orderBy('id') - 不支持
skip()/take()/paginate()等偏移类操作 - 示例：
use Illuminate\Support\LazyCollection; LazyCollection::make(function () { $lastId = 0; while (true) { $rows = User::where('id', '>', $lastId) ->orderBy('id') ->limit(1000) ->get(); if ($rows->isEmpty()) break; foreach ($rows as $row) { yield $row; $lastId = $row->id; } } })但更简单的是直接用内置cursor()：User::orderBy('id')->cursor()->each(function (User $user) { // 处理单个用户，内存无压力 });
chunkById() 更兼容老版本和复杂条件
如果你用的是 Laravel where、join、groupBy 导致 cursor() 不可用（会报 NotSupportedException），chunkById() 是更稳妥的选择。它用主键范围分片（WHERE id BETWEEN ? AND ?），避免 OFFSET 性能退化，且每 chunk 后自动释放模型引用。
立即学习“PHP免费学习笔记（深入）”；
- 必须指定主键字段名（如
chunkById(1000, 'id')），不能依赖隐式id - 注意：中间插入/删除数据可能导致某条记录被跳过或重复，业务上需幂等处理
- 比
chunk()安全——后者用OFFSET，数据量大时会越来越慢 - 示例：
User::where('status', 1) ->chunkById(500, function (Collection $users) { foreach ($users as $user) { $user->update(['processed' => true]); } }, 'id');
真正关键的不是“用了 LazyCollection”，而是“查询有没有避开全量加载”。只要走了 get() 或 all()，后面套什么都是马后炮。游标和分片才是数据库层的解法，PHP 层的 lazy 只是锦上添花。
