chunkbyid() 更稳因基于主键游标推进、不缓存builder实例，避免eloquent引用累积；需指定主键、禁用orderby、配合select字段；generator中每yield1000行调gc_collect_cycles()；db::unprepared()替代statement批量更新；队列中禁用model::all()改用chunkbyid。
chunkById() 为什么比 chunk() 更稳
用 chunk() 处理大数据时，内存不降反升很常见——不是它本身有 bug，而是 Eloquent 查询构建器会持续持有上一批模型的引用，尤其加了 with() 后更明显。而 chunkById() 基于主键游标推进，每次只查下一批 ID 范围，不缓存整个 Builder 实例，天然规避状态累积。
实操建议：
- 必须指定主键字段名：
chunkById(500, function ($users) { ... }, 'id')，否则默认用id，遇到 UUID 或复合主键会报错 - 不能和
orderBy()混用，chunkById()内部已按主键升序推进，额外排序会破坏游标逻辑 - 配合
select('id', 'name', 'email')使用，避免加载无用字段和关系属性
generator 导出里手动触发 gc_collect_cycles() 的时机
导出类实现 FromGenerator 接口时，generator() 方法里每 yield 一行数据，PHP 引用计数不会自动清零，尤其在循环中创建临时数组、调用辅助函数时容易残留。但太频繁调用 gc_collect_cycles() 反而拖慢速度。
实操建议：
- 每 yield 1000 行后调一次
gc_collect_cycles()，这是实测较平衡的节奏；低于 500 次会增加 GC 开销，高于 2000 容易触发 OOM - 别在
generator()里做数据库查询或 HTTP 请求——这些 IO 操作会阻塞生成器，且无法被 GC 回收连接资源 - 数据必须提前准备好：控制器中完成所有
where、when条件拼接，传入导出类的是最终的$ids或$rows数组，不是 QueryBuilder 实例
DB::unprepared() 替代 DB::statement() 批量更新
报表生成常伴随状态更新（如标记“已导出”），若用 DB::statement("UPDATE users SET exported = 1 WHERE id IN (?)", [$ids])，PDO 会为每个 IN 子句创建绑定上下文，内存占用随 ID 数量线性增长。而 DB::unprepared() 发裸 SQL，无绑定、无结果集解析。
实操建议：
- 用
array_chunk($ids, 1000)分组，再对每组拼接 SQL：DB::unprepared("UPDATE users SET exported = 1 WHERE id IN (" . implode(',', $chunk) . ")") - 注意 MySQL 的
max_allowed_packet限制，单条语句不要超过 4MB；本地开发可临时调大，生产环境建议严格控制每组 ≤1000 个 ID - 执行后手动清理连接缓存：
DB::connection()->getPdo()->setAttribute(PDO::ATTR_EMULATE_PREPARES, true)，缓解部分预处理残留
队列任务里 Model::all() 是内存炸弹
报表生成任务扔进队列后，如果还写 User::all() 或 User::get()，等于把全表记录一次性 load 进内存——哪怕只取 id 字段，Eloquent 也会实例化全部模型，每个对象自带 $attributes、$relations、$casts 等未使用属性。
实操建议：
- 永远用
User::query()->select('id', 'name')->chunkById(500, function ($users) { ... })替代all() - 如果只需统计或判断存在性，直接写原生 SQL：
DB::scalar("SELECT COUNT(*) FROM users WHERE status = 'active'") - 禁用模型监听器：
Event::forget('eloquent.*')，尤其在 Artisan 命令或队列中，避免隐式监听器持续持有模型引用
chunkById() 却没关监听器，或在 generator() 里偷偷查了库——内存问题从来不是单点故障，而是引用链悄悄闭合的结果。
