RabbitMQ 不支持传输大文件，Laravel 队列任务中不可序列化资源（如文件句柄、SplFileObject），必须将文件存外置存储（S3/MinIO等），任务仅传递路径、哈希等元数据；需调高 RabbitMQ frame_max、使用独立队列、设置 prefetch_count=1、worker 限制内存与超时，并用数据库协调分片状态。
直接说结论：RabbitMQ 本身不传大文件，Laravel 队列任务里也不能直接序列化 GB 级文件对象——必须切片、存外置存储、只传元数据。
为什么不能在 dispatch() 里传 $_FILES 或 fopen() 句柄
PHP 序列化机制无法序列化资源类型（如 file handle、PDO 连接、cURL 句柄），serialize() 会静默丢弃或报错；Laravel 的 SerializesModels trait 也只支持模型 ID 和基础标量。你看到任务进队列但 handle() 报 Undefined property: SplFileObject::$filename 或 Serialization of 'SplFileObject' is not allowed，就是这个原因。
- 所有文件内容必须先落地到外置存储（如本地
storage/app/uploads/、S3、MinIO） - 任务类构造函数只接收文件路径、ID、哈希值、分片索引等轻量元数据
- 在
handle()中用Storage::get($path)或file_get_contents($fullPath)按需读取 - 若需流式处理大文件（如 CSV 行级解析），用
fopen($fullPath, 'r')+fgets()，别一次性file_get_contents()
RabbitMQ 配置里这几个参数直接影响大任务吞吐
默认 RabbitMQ 配置对大消息极其不友好，128KB 是 AMQP 协议常见默认上限，超限直接被 broker 拒收，Laravel 日志里只显示 AMQPChannelException: PRECONDITION_FAILED - reply timeout 或静默失败。
-
RABBITMQ_MESSAGE_MAX_SIZE（非 Laravel 原生 env，需在 RabbitMQ server 端配置vm_memory_high_watermark和frame_max）：至少设为10485760（10MB） -
RABBITMQ_QUEUE必须显式指定，不要用默认default；大文件任务建议单独建队列，比如file_processing，避免和邮件、通知类小任务争抢 worker -
RABBITMQ_EXCHANGE_TYPE=direct必须保持，topic或fanout会放大路由开销，对高吞吐切片任务无益 - Laravel 驱动包（如
vork/laravel-queue-rabbitmq）要确认已启用content_encoding: utf-8和delivery_mode: 2（持久化），否则 worker 重启后未 ack 的大任务直接丢失
耗时任务切片的关键不是“分多少块”，而是“谁来协调完成状态”
把一个 2GB Excel 拆成 200 个 10MB 分片任务很简单，难的是怎么知道全部跑完了、哪几片失败了、要不要重试、结果怎么合并。RabbitMQ 本身不提供任务组（job group）或原子性事务语义。
- 用数据库表记录主任务生命周期：
file_tasks表存uuid、status（pending/processing/completed/failed）、total_chunks、processed_chunks - 每个分片任务
dispatch()时传入同一个$taskUuid，并在handle()结尾调用DB::table('file_tasks')->increment('processed_chunks') - 不要依赖 RabbitMQ 的 message count 判断完成——它不含重试、死信、未消费消息
- 加一个「守卫任务」：主任务 dispatch 后，再发一个延迟 5 分钟的
CheckFileTaskStatus，检查processed_chunks === total_chunks，触发合并或告警 - 切片逻辑放在 dispatch 前，不在
handle()里做；否则单个 worker 卡死会导致整个切片流程阻塞
worker 内存和超时必须硬约束，否则大文件任务会拖垮整台机器
一个没设限的 queue:work 进程处理大文件时，可能吃光 2GB 内存、占用 CPU 100% 持续 10 分钟，导致其他队列积压、Supervisor 无法拉起新进程。
- 强制使用
--max-jobs=1：每个分片任务独占一个进程，避免内存累积（虽然开销略大，但稳定优先） - 必须配
--timeout=600（10 分钟），防止某一分片因磁盘慢或网络卡住无限 hang 住 - 在
handle()开头加ini_set('memory_limit', '512M');，但注意这不能超过 PHP-FPM 或 CLI 的全局限制 - 用
pcntl_signal(SIGTERM, ...)捕获中断信号，在 worker 被 kill 前主动释放文件句柄、更新 DB 状态 - 日志里务必记录每片的
microtime(true)起止时间，方便后续分析瓶颈是 IO、CPU 还是外部 API
真正容易被忽略的点：RabbitMQ 的 prefetch_count。默认是 0（无限制），worker 会一口气拉取几十个分片任务到内存，还没开始处理就 OOM。生产环境必须在 config/queue.php 的 rabbitmq 连接里设 'options' => ['prefetch_count' => 1]，让 worker 一次只拿一个分片，处理完再取下一个。
