cometd 基于 bayeux 协议（json 格式）设计，不支持消息内容的流式分块传输（partial messaging），无论 5.x 还是 7.x 版本；处理大体积数据应改用 http 或自定义 websocket 子协议传输，而非复用 cometd 消息通道。
cometd 基于 bayeux 协议（json 格式）设计，不支持消息内容的流式分块传输（partial messaging），无论 5.x 还是 7.x 版本；处理大体积数据应改用 http 或自定义 websocket 子协议传输，而非复用 cometd 消息通道。
CometD 的核心定位是轻量、可靠、低延迟的事件驱动双向通信，其消息模型严格遵循 Bayeux 协议规范：每条消息必须是完整、自包含、可独立解析的 JSON 对象（如 { "channel": "/service/chat", "data": { ... } }）。这意味着：
- ✅ 支持消息批处理（batching）、确认（acknowledgment）、订阅/退订语义；
- ❌ 不支持单条消息的分片（fragmentation）、流式写入（streaming write）或分块接收（partial read）；
- ❌ 无法在 WebSocket 层对一条逻辑消息进行多帧拆分并按序重组——这与 Bayeux 的原子性、幂等性和状态一致性设计相冲突。
例如，以下伪代码试图发送一个超大附件对象，在 CometD 中是不可行的：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
// ❌ 错误示例：CometD 不允许“分块发送”同一 message
client.publish("/chat/upload", largeFileChunk1); // 不是标准用法
client.publish("/chat/upload", largeFileChunk2); // CometD 视为两条独立消息正确的架构实践是：分离控制面与数据面。
✅ 推荐做法：
- 使用 CometD 交换元数据（如上传任务 ID、临时 URL、校验摘要）；
- 通过标准 HTTP PUT/POST（或专用 WebSocket 子协议）传输原始二进制数据；
- 利用 HTTP 的
Content-Range、Transfer-Encoding: chunked或自定义流协议实现真正的分块上传/下载。
// ✅ 正确示例：CometD 仅传递控制指令
Map<String, Object> uploadMeta = Map.of(
"taskId", "upload_abc123",
"uploadUrl", "https://api.example.com/uploads/abc123",
"expiresAt", System.currentTimeMillis() + 300_000L
);
client.publish("/service/upload/request", uploadMeta); // 完整 JSON 消息
// 后续由客户端直接发起 HTTP 请求上传文件（支持分块、断点续传等）
// POST https://api.example.com/uploads/abc123
// Content-Type: application/octet-stream
// (分块发送二进制流，与 CometD 无关)⚠️ 注意事项：
- 升级至 CometD 7.x 并不会带来 partial messaging 支持——该能力不在 Bayeux 协议范畴内，官方亦无计划引入；
- 若强行在应用层模拟“分块”，需自行实现序列号、重传、乱序重组、超时控制等，复杂度高且易破坏 CometD 的可靠性保证；
- 第三方库（如 Netty、Spring WebFlux、OkHttp）可辅助实现高效流式 HTTP/WebSocket 传输，但它们与 CometD 是正交技术栈，不可“集成”为 CometD 的扩展功能。
总结：CometD 是事件总线，不是文件传输管道。面对大体积数据场景，请坚持“小消息 + 大数据分离”的架构原则——用 CometD 做调度，用 HTTP/WebSocket 做搬运，方能兼顾实时性、可靠性与可扩展性。
