Java中用StringBuilder高效拼接URL查询参数需预估容量、链式append、严格编码value。先确认基础URL是否含?，再初始化StringBuilder(128+)，仅encode值，避免+和toString()混用。
在 Java 中用 StringBuilder 高效拼接 URL 查询参数，核心是避免字符串临时对象、控制扩容、规范编码逻辑。它不是简单“把参数连起来”，而是兼顾性能、可读性与安全性。
明确起始结构，避免重复解析
URL 拼接通常分两段：基础路径（含协议、host、path）和查询参数（?key=value&key2=value2）。不要在 StringBuilder 里从头拼整个 URL 字符串再做 Uri.parse()，而应先确认基础 URL 是否已含 ?：
- 若基础 URL 确定不含查询参数（如
"https://api.example.com/v1/user"），直接追加"?"开始拼参 - 若可能带已有参数（如动态 path 后已含
?format=json），先用Uri.parse()解析再用Uri.Builder追加更稳妥——StringBuilder不负责语义校验，强行拼容易破坏结构
预估容量，减少数组复制
每次扩容都要复制旧数组，对高频或大批量请求影响明显。假设你要拼 5 个参数，每个键名平均 6 字符、值平均 12 字符，加上等号、&、?，粗略估算：
- 基础部分（如
"https://a.b/c?"）约 20 字符 - 5 个参数：5 × (6 + 1 + 12) = 95 字符
- 分隔符：4 个
&→ 4 字符 - 总长 ≈ 120 字符 → 建议初始化
new StringBuilder(128)或160（留余量）
不预估也行，但默认 16 容量下拼 10+ 参数大概率触发 3~4 次扩容，实测耗时可差 2–3 倍。
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
链式 append，不混用 + 和 toString()
写法要干净，每一步都调用 append()，别在中间插 + 或提前 toString()：
- ✅ 推荐：
sb.append("name=").append(URLEncoder.encode(name, "UTF-8")).append("&age=").append(age) - ❌ 避免：
sb.append("name=" + URLEncoder.encode(name, "UTF-8"))—— 这会让编译器额外建一个 StringBuilder 处理+，白费力气 - ❌ 避免：
sb.append(paramString()).toString()在循环中反复调用 —— 每次都生成新 String，失去 StringBuilder 意义
数字类型直接用 append(int)、append(long)，比 append(String.valueOf(x)) 少一次装箱/转换。
必须处理编码，不能跳过
URL 参数值含空格、中文、斜杠等时，不编码会导致请求 400 或服务端解析失败。注意：
-
URLEncoder.encode(value, "UTF-8")是必须步骤，且只编码 value，key 一般为固定英文可不编（但编码更保险） - 编码后会把空格转成
+，斜杠转成%2F，这些是标准行为，无需手动替换 - 不要用
URLDecoder.decode()反向操作，拼接阶段只做 encode
如果参数来自用户输入或外部数据，漏掉这步几乎必然出错，性能再好也没用。
