StringBuilder用于高效组装待发送报文，如HTTP请求体、TCP协议包等，需预估容量、手动转义、链式append且用完即弃。
在网络协议解析场景中，StringBuilder 主要用于**高效组装待发送的报文**（如 HTTP 请求体、自定义 TCP 协议包、心跳帧等），而非解析已收到的原始字节流。它不参与解码、校验或结构分析，只承担“快速拼出合法字符串”的任务——关键在可控、固定、低开销。
适用报文类型：结构简单、字段稳定、无嵌套
适合用 StringBuilder 组装的协议报文需满足三个条件：字段来源可信（非用户直输）、结构扁平（无对象嵌套/动态数组）、格式规则明确（如固定分隔符、固定键名）。典型例子包括：
- HTTP 查询参数拼接：
name=Zhang%20San&age=25&city=Beijing - 自定义二进制协议的文本头：
LEN:128|VER:2|CMD:LOGIN|TS:1712345678900 - 心跳包 JSON：
{"type":"heartbeat","seq":123,"ts":1712345678}（字段全为清洗后数值或短字符串） - 日志上报行协议（类似 Syslog 格式）：
2026-08-20T22:43:01.123Z INFO [user-login] uid=U123456 status=success
初始化容量必须预估，避免扩容抖动
网络 I/O 往往是性能敏感路径，一次报文拼接若触发多次扩容（如从 16→34→70→142…），会带来额外数组复制开销。应根据字段数量、平均长度和分隔符数量粗略估算总长：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 例如拼接 5 个字段（uid、action、ip、ts、status），平均 12 字符 + 4 个
|分隔符 → 约 64 字符 →new StringBuilder(72) - HTTP 参数含 URL 编码，中文会膨胀为 %xx 形式，估算时按原始字符 × 3 计（如 “张三” →
%E5%BC%A0%E4%B8%89共 18 字符） - 不确定上限但数据量大（如批量上报 100 条记录），设 2048 或 4096 更稳妥，比频繁扩容划算
手动转义与格式控制不可省略
StringBuilder 不做任何语义检查，所有协议合规性责任在开发者手上：
立即学习“Java免费学习笔记（深入）”；
- HTTP 查询参数值必须 URL 编码：
URLEncoder.encode(value, StandardCharsets.UTF_8)，不能直接append(value) - 自定义分隔协议中，若字段本身含
|，需提前约定转义规则（如改为\|）并统一处理 - JSON 片段若必须手拼（不推荐），双引号内嵌引号必须写成
\"，布尔值写true而非"true"，数字不加引号 - 避免拼出非法换行或空格：HTTP 报文头要求 CRLF（
\r\n），不要用\n替代
链式 append + 局部作用域使用最安全
拼接逻辑应限制在单次请求/连接的局部范围内，用完即弃：
- 推荐写法：
sb.append("CMD:").append(cmd).append("|TS:").append(ts).append("|DATA:").append(encode(data)) - 禁止在循环中混用
+和append，如sb.append("a" + "b")会白建临时 StringBuilder - 不要将 StringBuilder 作为类成员变量长期持有；多线程环境绝对不共享实例（用 ThreadLocal 包裹可复用，但需每次
setLength(0)清空） - 拼接完成后务必调用
toString()获取最终字符串，再传给OutputStream或 HTTP 客户端
