Collectors.joining 性能优势源于语义清晰、避免手动错误及与流天然契合，内部基于优化的 StringJoiner，预分配容量且支持分隔符/前后缀封装，适用于已存在流管道的场景，并需配合 null 和空白过滤保障稳定性。
为什么 joining 性能表现好？
它内部使用了优化的 StringJoiner（JDK 8 引入），而非简单循环 + StringBuilder 拼接。StringJoiner 预分配容量、复用 char 数组、避免多次扩容，尤其在元素数量可预估（如集合 size 已知）时，性能接近手写 StringBuilder。
更重要的是：它把「拼接逻辑」从业务代码中解耦，让 stream 管道保持声明式风格，减少出错可能——比如漏掉分隔符、误拼 null、忘记 trim 空格等，这些隐性成本远高于微秒级的执行差异。
三种重载方式对应不同开销场景
-
joining()：零开销分隔/封装，纯追加。适合路径片段、编码标识等，如
["v1", "user", "profile"] → "v1userprofile" - joining(delimiter)：最常用。内部维护分隔符状态，仅在非首元素前插入，无冗余判断。适合日志字段、CSV 字段、SQL IN 列表等
-
joining(delimiter, prefix, suffix)：一次性完成封装，避免后续
"[" + s + "]"类字符串拼接。适合生成 JSON 数组项、带引号的 SQL 字面量等
真正影响性能的关键点不在 joining 本身，而在前置操作
常见低效写法是：为了用 joining 而强行构造 stream，例如对小 List 单独调用 list.stream().collect(joining())。此时创建 stream 的开销反而超过收益。
高效用法只在以下情况体现价值：
立即学习“Java免费学习笔记（深入）”；
- 已在流管道中：比如
users.stream().filter(...).map(User::getName).collect(joining(", ")) - 配合 flatMap 多层展开后拼接：
orders.stream().flatMap(o -> o.getItems().stream()).map(Item::getId).collect(joining("|")) - 并行流处理大批量数据时，joining 收集器支持安全合并（combiner），无需额外同步
必须做但常被忽略的安全处理
joining 不处理 null，也不跳过空字符串。若源数据含 null 或空白，不清理会直接抛 NullPointerException 或生成脏数据：
- 过滤 null：
.filter(Objects::nonNull) - 同时过滤 null 和空白：
.filter(s -> s != null && !s.trim().isEmpty()) - 慎用 map 转空串：
.map(s -> s == null ? "" : s)—— 这会让 "" 参与拼接，可能不符合语义
这步过滤看似增加操作，实则避免运行时异常和修复成本，是性能稳定性的前提。
不复杂但容易忽略
