Scatter/Gather是Channel与ByteBuffer数组协同的高效I/O模式：Scatter一次read按序填充header+body等多个Buffer，用于解析结构化报文；Gather一次write按序写出多个已flip的Buffer，用于构造响应消息；仅支持FileChannel和非阻塞SocketChannel，需确保Buffer类型一致、顺序敏感并检查返回值。
Scatter/Gather 不是用来“发送”头与体的组合消息的，而是用来高效解析和构造这类结构化网络报文的。关键在：Scatter 用于接收端按顺序填满 header + body Buffer；Gather 用于发送端按顺序写出已准备好的 header + body Buffer —— 两者都依赖固定布局、类型一致、非阻塞通道，并需手动管理 Buffer 状态。
协议头+体分散读取（Scatter）：接收端解析
适用于服务端读取客户端发来的定长头+变长体报文，例如 4 字节长度字段 + 后续 JSON 内容。
- 分配两个 DirectByteBuffer：headerBuf（capacity = 4）、bodyBuf（capacity = 预估最大负载，如 8192）
- 确保 channel 已设为非阻塞，并注册到 Selector 监听 OP_READ
- 调用 channel.read(new ByteBuffer[]{headerBuf, bodyBuf})；NIO 自动先填满 headerBuf（4 字节），再把剩余字节写入 bodyBuf
- 检查返回值：若 read() 返回 0 或部分字节数（如只收到 2 字节），说明数据未就绪，不能 flip，需等待下一次 OP_READ 就绪后再重试
- 仅当 read() 返回 ≥ 4 时，才对 headerBuf.flip() 并读出 length 字段；再根据该值判断 body 是否收全（bodyBuf.position() 是否等于 length），否则继续等待
协议头+体聚集写入（Gather）：发送端构造响应
适用于服务端拼装状态码、JSON 响应体、换行符等逻辑上一体、物理上分离的内容。
- 预先准备好多个已写入数据并 flip() 的 Buffer：statusBuf.put((byte)'O').put((byte)'K').flip()、jsonBuf.put("{'code':0}".getBytes()).flip()、crlfBuf.put((byte)'\r').put((byte)'\n').flip()
- 调用 channel.write(new ByteBuffer[]{statusBuf, jsonBuf, crlfBuf})；NIO 按数组顺序依次写出各 Buffer 的 remaining() 字节（即只写有效内容，不补零）
- 检查返回值：若未全部写出（如网络缓冲区满），write() 返回实际字节数；未写完的 Buffer 仍保持当前 position/limit，下次可直接复用 write() 继续发送，无需重新 flip 或 clear
- 所有 Buffer 必须同为 heap 或同为 direct；推荐全用 direct，避免 JVM 堆内拷贝开销
必须避开的典型陷阱
这些错误会导致数据错位、读写失败或行为未定义：
- 用在 DatagramChannel 上：Scatter/Gather 仅支持 FileChannel、SocketChannel（非阻塞）、ServerSocketChannel；UDP 通道不支持
- Buffer 类型混用：比如 headerBuf 是 heap，bodyBuf 是 direct，read/write 可能抛 UnsupportedOperationException
- 未等 header 填满就尝试 flip：Scatter 要求前一个 Buffer 必须写满才会写下一个，header 容量是 4 就必须收齐 4 字节才能进 body；动态头长不适用此模式
- write 前忘了 flip，或 write 后误调 clear：flip 是为了设置 limit=position、position=0，让 write 能读出数据；clear 会重置一切，导致空内容被写出
为什么比手动 copy 更高效？
底层由操作系统直接操作内存地址，避免了 JVM 层面的 byte[] 合并、额外复制、GC 压力。尤其在高频小消息场景（如微服务间 RPC 响应），Gather 能将 status、headers、payload 分别填充再一次性发出，吞吐提升明显；Scatter 则让协议解析无需额外 buffer.slice() 或 arraycopy，头体天然隔离，线程安全更易保障。
