ByteArrayOutputStream 不适合拼装复杂二进制协议包，因其扩容被动低效、无法预分配、不支持回填、reset() 不真正清空且 toByteArray() 总返回全量副本。
ByteArrayOutputStream 不适合拼装“复杂”二进制协议包——它的动态扩容是被动、低效且不可控的，真要高效拼装，得绕开它或严格限定使用边界。
为什么 ByteArrayOutputStream 的扩容机制在协议拼装中反而拖后腿
它的扩容逻辑很简单：当前 buf.length 不够写就新建一个 2 倍大小的数组，把旧数据 System.arraycopy 过去。问题在于：
- 每次扩容都触发一次完整拷贝，写入 1MB 数据中途扩容 10 次，就拷贝了约 2MB 内存
- 扩容阈值固定（
buf.length * 2），无法按协议头/体/尾的已知尺寸预分配，容易浪费或频繁触发 - 没有 position/limit 管理，无法回填字段（比如先写占位长度，再填完正文后回头改长度）
-
reset()后仍保留原数组，若后续写入量远小于之前，toByteArray()返回的仍是大数组，前缀有效、后面全是脏数据
什么情况下它还能凑合用——仅限“线性追加 + 无回填 + 小体积”
如果你的协议包满足以下全部条件，ByteArrayOutputStream 才算勉强可用：
- 所有字段顺序固定、无需跳转写入（如：魔数 → 版本 → payload 长度 → payload）
- payload 长度可提前预估（例如最大 64KB），构造时传入合理初始容量：
new ByteArrayOutputStream(65536) - 最终包体 ≤ 几百 KB，且不高频创建（否则 GC 压力明显）
- 不需要复用实例——每次 new 一个比调
reset()更干净
示例：拼一个无长度校验、纯追加的简单心跳包
ByteArrayOutputStream baos = new ByteArrayOutputStream(32); baos.write(0x48); // 'H' baos.write(0x45); // 'E' baos.write(0x41); // 'A' baos.write(0x52); // 'R' baos.write(0x54); // 'T' byte[] packet = baos.toByteArray(); // 安全，只含这 5 字节
真正高效拼装二进制协议包的替代姿势
要支持回填、复用、零拷贝、大小可控，必须换工具：
- 用
ByteBuffer：调putShort(0)写占位长度 → 填 payload →putShort(2, (short) payloadLen)回填；flip()后可直接传给SocketChannel.write() - 用 Okio
Buffer：支持分段写入、自动管理内存、writeIntLe()等协议友好方法，buffer.readByteString(size)可安全截取子段 - 手写协议类 + 预分配
byte[]：定义class ProtoPacket { final byte[] buf = new byte[1024]; int pos = 0; }，自己管写入和回填，无额外对象开销
关键点不是“能不能拼”，而是“拼的过程中要不要跳转、重写、复用、控制内存布局”——ByteArrayOutputStream 对后三者基本无解。
最容易被忽略的坑：toByteArray() 的副本语义和 reset() 的假清空
很多人以为 baos.reset(); baos.write(newData); 就是“清空重来”，但实际：
-
toByteArray()每次都 new 一个数组，如果之前写过 1MB，现在只写 10 字节，返回的仍是 1MB 数组（前 10 字节新，后面全是旧垃圾） - 没调
reset()直接反复write()，会持续扩容，内存里堆着多个废弃大数组 - 若协议要求严格字节对齐（如 4 字节整除），
ByteArrayOutputStream完全不提供 pad 或 align 方法，只能手动补 0 并自己算偏移
这些细节在小流量测试时完全不显，一到高并发或大数据包就暴露为 GC 飙升、OOM 或协议解析错位。
