Generator并非自动省内存，其内存安全取决于yield外的操作：如未释放模型、未关日志、或在生成器中collect全量数据；PDO模拟预处理默认开启导致cursor()内存持续增长，须禁用并启用服务器端游标；FromGenerator不自动GC，需手动gc_collect_cycles()；chunk闭包易因变量引用致内存泄漏；ORM关联加载会彻底破坏Generator的内存优势。
Generator 不是“自动省内存”的银弹，它只保证数据产出方式是惰性的；真正决定内存是否爆掉的，是你在 yield 之外干了什么——比如没释放模型实例、没关查询日志、或在生成器里偷偷 collect() 全量数据。
cursor() 为什么越跑内存越高？关键在 PDO 预处理模式
Laravel 的 cursor() 确实返回 Generator，但底层用的是 PDO 的游标式查询。问题出在 PDO::ATTR_EMULATE_PREPARES 默认为 true（尤其 MySQL）：PDO 会把整张表结果集缓存在客户端内存里，再模拟游标“逐条吐”，实际根本没释放前序数据。
- 必须显式关闭模拟预处理：
DB::connection()->getPdo()->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); - 同时确保数据库连接启用了真正的服务器端游标（MySQL 5.7+ 默认支持，PostgreSQL 原生支持）
- 验证是否生效：执行
SHOW VARIABLES LIKE 'max_allowed_packet';和SELECT @@session.sql_mode;，避免因 SQL 模式触发隐式全量加载
FromGenerator 导出时 yield 后不 gc，内存照样涨
FromGenerator 接口本身不保你内存安全。你在 generator() 方法里 yield 每行数据，但如果每行都 new 一个 Eloquent 模型、或调用 toArray() 生成大数组，Generator 只管“吐”，不管“清”。
- 永远避免在
generator()中调用Eloquent::get()、collect()或任何一次性加载全量的方法 - 直接从 DB 查询原始数组：
DB::table('users')->select('id', 'name', 'email')->cursor()，再yield每行$row - 手动触发垃圾回收不是可选优化，而是必要操作：
if ($i % 1000 === 0) { gc_collect_cycles(); }，尤其在 long-running 进程中
chunk() 和 chunkById() 的隐藏陷阱：闭包变量引用导致内存泄漏
chunk() 看似安全，但它把整批结果传进闭包——这批数据只要闭包没退出，就一直被 PHP 引用计数持有。更隐蔽的是，如果你在闭包里用了 $this、捕获了外部变量、或调用了带静态缓存的辅助方法，引用链会意外延长。
- 闭包内禁止使用
$this->someProperty，改用参数传入所需值 - 避免在 chunk 闭包里调用
Cache::remember()或app()，它们可能持有所谓“全局上下文” - 对超大表，优先用
chunkById()并配合select('id')先捞 ID 列，再分批查详情，避免单次结果集膨胀
最常被忽略的一点：所有这些 Generator 优化，都建立在“你没在循环里做 ORM 关系加载”基础上。一旦 yield $user->posts，Eloquent 就会 eager load 全部关联数据——那 Generator 就只是个精致的棺材板。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
