不能直接将大buffer传入channel.publish()，因rabbitmq协议不支持流式传输，且易触发node.js内存溢出及服务端frame_error；须通过流式分块、元数据标记与消费者端可靠拼接实现。
为什么不能直接把大 Buffer 丢进 channel.publish()
因为 RabbitMQ 协议本身不支持流式传输，channel.publish() 要求传入的是完整、可序列化的 Buffer 或字符串。如果你用 fs.readFileSync() 读一个 500MB 文件再发，Node.js 进程内存会瞬间暴涨，还可能触发 V8 内存限制（如 FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory）。更糟的是，哪怕你硬扛住内存压力，单条消息超过 RabbitMQ 默认的 frame_max（通常 128KB），服务端会直接断连并报错：FRAME_ERROR - expected 'channel' frame, got non-frame data。
必须先切片：用 stream.Readable.from() + pipe() 控制 chunk 大小
核心思路是：不落地、不全加载，让数据从源头（比如文件或 HTTP 响应）流经可控大小的分块逻辑，再逐块 publish。关键不是“怎么切 Buffer”，而是“怎么让 Stream 自动按需吐出固定 size 的 chunk”。
-
fs.createReadStream(filePath)或任何可读流作为源头，不要用fs.readFileSync() - 用
stream.Transform实现分块逻辑：累积数据直到达到目标大小（如 100KB），然后 push 一个新Buffer；剩余部分留到下次 - 每块输出都走
channel.publish()，并带上唯一correlationId和messageId，方便消费者拼接 - 注意设置
channel.prefetch(1)防止生产者压垮消费者，尤其当分块数多时
channel.publish() 发送分块时必须设对这些选项
光切片不够，RabbitMQ 对每块消息的元数据和交付语义有隐含要求，否则消费者无法可靠还原原始流。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
-
contentType设为"application/octet-stream"，避免 AMQP 自动转码 -
headers至少包含：{ "chunk-index": 0, "total-chunks": 12, "original-filename": "video.mp4" }—— 不要用 message body 存元信息，body 只放纯二进制数据 -
deliveryMode: 2（持久化）必须开，否则某块消息丢失会导致整个流不可恢复 - 禁用
mandatory和immediate，它们在集群或镜像队列场景下容易导致意外丢弃
消费者端还原流时最容易漏掉的三件事
发送端切得再准，消费端拼错一块就全废。这不是“收到就写文件”那么简单。
- 必须按
correlationId分组缓存分块，不能只靠chunk-index—— 同一原始流的多批次消息可能混在同一个队列里 - 用
Map+Set管理未完成的流：key 是correlationId，value 是{ chunks: Buffer[], received: Set<number>, total: number }</number> - 收到最后一块（
chunk-index === total-chunks - 1）后，才执行Buffer.concat(chunks)并触发业务逻辑；中间任何一块超时（比如 30s 未收齐），要主动清理缓存防内存泄漏
真正难的从来不是怎么发，而是怎么让接收方在无状态、分布式、可能重启的环境下，把离散的 AMQP 消息重新聚合成原始字节流 —— 元数据设计、超时策略、错误清理，缺一不可。
