bytearrayoutputstream 本质是可增长 byte[]，适合轻量线性拼装；但用于复杂二进制报文时，其非翻倍扩容（old×2+2）、无法回填、tobytearray() 返回副本等特性易引发性能与逻辑问题。
ByteArrayOutputStream 的动态缓冲区本质是一个可增长的 byte[]，它适合轻量、线性、无回填的字节拼装；但若用于复杂二进制报文（如含包长字段、CRC、多段嵌套结构），其扩容机制和数据模型会成为性能与逻辑隐患的源头。
扩容机制：不是翻倍，而是 old × 2 + 2
底层维护一个 byte[] 和 count 计数器。默认初始容量为 32 字节。每次写入前调用 ensureCapacity() 判断是否需扩容；若需，则执行 grow(minCapacity)，新容量按公式 oldCapacity × 2 + 2（JDK 8+）计算，而非简单 ×2。这个设计在小数据时避免过度分配，在中等尺寸时控制扩容次数，但对大报文（如 1–10 MB 协议帧）仍可能触发 10 次以上数组拷贝，每次拷贝都调用 System.arraycopy，带来明显 CPU 和内存带宽开销。
- 写入 1MB 数据，若从 32 字节起步，典型扩容路径为：32 → 66 → 134 → 270 → 542 → 1086 → … → 超过 1MB，共约 15 轮拷贝
- 预估最大长度并显式传入构造参数（如 new ByteArrayOutputStream(1024 * 1024)）可彻底规避扩容
- 扩容不加锁，多线程共用同一实例会导致数据错乱或数组越界
toByteArray() 返回副本，无法“回填”字段
该方法每次调用都 new 一个完整数组，复制当前 count 个有效字节。它返回的是快照，不是底层 buf 的引用视图。因此：
- 不能先 toByteArray() 获取数组，再修改某字节来更新报文头——修改只作用于副本，不影响 ByteArrayOutputStream 内部状态
- 需要“动态回填”的字段（如 4 字节总长、2 字节校验和），必须先占位（例如 write(new byte[4])），全部写完后再调 toByteArray() 得到最终数组，手动按索引填入计算值
- reset() 只重置 count = 0，buf 数组仍保留原内容；下次 write() 是覆盖写，但未覆盖区域仍是脏数据，toByteArray() 仍返回全量有效字节 + 后缀脏字节（除非 reset 后立即重写满）
适用边界：仅限“顺序追加 + 小体积 + 无结构依赖”
它真正安全高效的使用场景非常有限，需同时满足：
- 协议字段严格线性排列（魔数→版本→命令码→负载），无跳转、无条件分支写入
- 负载长度可提前预估（如固定 64KB 心跳体），构造时指定合理初始容量
- 单次报文 ≤ 512KB，且非高频创建（避免堆内存碎片和 GC 压力）
- 无需复用实例——每次 new 更干净，比 reset() 更可控
例如拼接纯 ASCII 文本日志片段、简单无校验的设备指令（HEART、PING 等），就属于典型可用场景。
更优替代方案：面向协议设计的工具链
当报文含头部/载荷分离、需回填、零拷贝导出或要求内存布局精确时，应切换技术栈：
- ByteBuffer：支持 position/limit/flip，可 putInt(0) 占位、put(payload) 写载荷、putInt(0, realLen) 回填；flip() 后可直接传给 SocketChannel.write()，无额外拷贝
- Okio Buffer：提供 writeShortLe()、writeInt()、readByteString() 等协议友好 API，自动管理分段内存，支持安全截取子段
- 手写协议类 + 预分配 byte[]：定义 ProtoPacket { final byte[] b; int pos; }，封装 writeU16At()、writeU32At() 等方法，完全掌控内存布局与生命周期
