bytearrayoutputstream 无真正缓存机制，仅是可扩容字节数组容器；其高效仅限于一次性构造小体积、结构固定且写完即导出的协议包，超出则性能与语义迅速劣化。
ByteArrayOutputStream 没有真正意义上的“缓存机制”，它只是个可扩容的 byte[] 写入容器；所谓“高效拼装”仅在**一次性构造小体积、结构固定、写入后立即导出**的协议包时成立。超出这个范围，性能和语义都会迅速劣化。
为什么 toByteArray() 一调就变慢？
每次调用 toByteArray() 都会创建一个新数组，并把当前 count 字节拷贝过去——这不是引用，也不是视图。如果之前写过 8KB，中间 reset() 过两次，但底层数组仍为 8KB，那么：
- 即使只写了 10 字节，
toByteArray()返回的仍是 8KB 数组（前 10 字节有效，其余是旧数据） - 若后续写入超过 8KB，底层数组再次扩容，JVM 里同时存在两块大数组，GC 压力陡增
- 反复 write → toByteArray() → write，等于在做隐式内存复制，不是“复用”而是“泄漏”
哪些协议包适合用 ByteArrayOutputStream 拼装？
只适用于满足全部以下条件的场景：
- 总长度可控（≤ 4KB），且结构简单（如 HTTP 响应头 + 小段 JSON）
- 写入过程无分支重试、无动态长度回填（比如不需先预留 4 字节长度位再填值）
- 拼装完立刻转成
byte[]交给下游（如传给SocketChannel.write()或ObjectOutputStream） - 不跨线程共享实例，也不长期持有（new 一次用一次，别塞进静态池）
示例：拼一个带固定 Magic Number 和版本号的请求头
ByteArrayOutputStream baos = new ByteArrayOutputStream(64);
baos.write(new byte[]{0x42, 0x45, 0x45, 0x46}); // magic
baos.write(1); // version
baos.write(0); // reserved
byte[] header = baos.toByteArray(); // 安全，64 字节内，无回填逻辑
reset() 不是清空，是埋雷
reset() 只做一件事：count = 0。底层数组 buf 一字未动，内容全留着。下次 write() 从索引 0 开始覆写，但：
- 若新数据比旧数据短，
toByteArray()返回的数组里残留大量脏字节（可能被下游误解析） - 若新数据更长，触发扩容，老数组不会被回收，直到 baos 被 GC
- 没有任何机制标记“哪些字节有效”，业务层必须自己维护 length 边界——这已经脱离了
ByteArrayOutputStream的设计契约
真要高效拼协议包，该换什么？
当协议含动态长度字段、需多次回填、或单包超几 KB 时，直接换用 ByteBuffer：
- 用
ByteBuffer.allocate(4096)预分配，put()写入，flip()切换读模式，array()+arrayOffset()+limit()精确拿到有效段，零拷贝 - 需要回填长度？
putInt(0, length)先占位，写完再putInt(0, actualLength) - 线程安全？每个连接独占一个
ThreadLocal<bytebuffer></bytebuffer>，避免同步开销 - 嫌手动管理麻烦？用 Netty 的
PooledByteBufAllocator，自动回收+池化+堆外支持
别试图用 ByteArrayOutputStream 模拟 ByteBuffer 的行为——它没 position/limit/capacity 三态控制，也没有翻转、压缩、切片能力，硬撑只会让边界逻辑散落在各处，调试时连哪段字节是哪次 write 写的都分不清。
