chunkbyid比chunk更安全，因其基于主键范围查询而非offset，避免漏行、重复或卡死；需确保id自增有序、不修改id、回调内按需小事务。
分批处理大表时 chunkById 为什么比 chunk 更安全
因为 chunk 依赖 OFFSET，数据量大或写入频繁时容易漏行、重复或卡死；chunkById 基于主键范围查询，稳定且可中断续跑。
实操建议：
• 必须确保模型有自增整型 id（或显式指定 orderBy('id') 的有序字段）
• 不要改查出的记录 id，否则下次分片会跳过或重叠
• 每次回调里别用 DB::transaction 包裹整个 chunk，而应在回调内按需开启小事务
• 示例：
$users->chunkById(1000, function ($chunk) {<br> foreach ($chunk as $user) {<br> $user->update(['status' => 'processed']);<br> }<br>});
Laravel 分批导出 CSV 时内存爆掉怎么办
直接 get() 全量加载进内存是常见错误，尤其百万级数据。
实操建议：
• 用 LazyCollection::make() + cursor() 流式读取，不缓存结果集
• 导出逻辑不要在闭包里拼接大字符串，改用 fputcsv 直接写文件句柄
• 避免在循环中调用 Eloquent 访问器或关系（如 $user->posts），会触发 N+1
• 示例关键片段：
LazyCollection::make(function () {<br> $query = User::query()->select('id', 'name', 'email');<br> foreach ($query->cursor() as $user) {<br> yield [$user->id, $user->name, $user->email];<br> }<br>})->each(function ($row) use ($fp) {<br> fputcsv($fp, $row);<br>});
分片任务跑一半失败，怎么从断点继续
Laravel 默认不记录分片进度，断点续传得自己管。
实操建议：
• 在每次 chunkById 回调末尾写入当前最大 id 到缓存或数据库（如 cache()->put('user_process_last_id', $chunk->last()->id)）
• 下次启动前先查这个值，用 where('id', '>', $lastId) 构造新查询
• 不要用时间戳字段做分片依据（如 created_at），可能有重复值或时区问题
• 注意缓存失效策略：设个合理过期时间（比如 24 小时），避免旧断点卡住新流程
多租户场景下分片必须避开的坑
租户隔离没做好，chunkById 可能跨租户拉数据，或者分片逻辑被全局作用域干扰。
实操建议：
• 确保模型已正确启用租户作用域（如 BelongsToTenant trait），并在分片前显式调用 withGlobalScope 或检查 static::$globalScopes
• 不要在分片回调里切换租户上下文（如 Tenant::set()），会导致后续 chunk 查询错库
• 最稳妥做法：每个租户单独走一遍分片流程，用队列 job 分拆，job 参数只传 tenant_id 和起始 id
• 验证方式：在 chunk 回调开头加 Log::debug("Processing tenant {$tenantId}, ids: [{$chunk->first()->id}, {$chunk->last()->id}]")
chunkById 的“by id”三个字，真正在意的是那个 id 是否全局唯一、单调、不可变。
