在Java开发中，将集合中的元素转换为字符串的需求随处可见。举个最常见的例子：前端传过来一组用户ID，你需要拼成逗号分隔的字符串塞进SQL的in条件里；或者日志输出时，想把一个List的内容以可读的形式打印出来。虽然这看起来是个小操作，但不同的实现方式在性能、可读性和边界处理上差别不小，选错了写法还可能埋下隐患。本文就来系统地梳理几种主流的转换方式。
传统循环拼接与StringBuilder方式
最直接的思路就是遍历集合，把每个元素追加到一个StringBuilder中，元素之间用指定的分隔符隔开。这种方式在JDK 8之前的代码里非常普遍，理解起来没有任何门槛，而且对分隔符、前后缀的控制完全由自己掌握。
不过手写循环拼接有个经典的小坑：第一个元素前面不应该出现分隔符。不少初学者会直接在每个元素后面加分隔符，导致结果末尾多出一个逗号，最后还得额外调用一次deleteCharAt或者substring去裁剪。下面是两种典型写法的对比：
// 写法一：在元素前面加分隔符，需处理首元素
List<String> list = Arrays.asList("apple", "banana", "cherry");
StringBuilder sb = new StringBuilder();
for (String item : list) {
if (sb.length() > 0) {
sb.append(",");
}
sb.append(item);
}
String result = sb.toString(); // apple,banana,cherry
// 写法二：末尾追加分隔符，最后裁剪掉
StringBuilder sb2 = new StringBuilder();
for (String item : list) {
sb2.append(item).append(",");
}
String result2 = sb2.length() > 0
? sb2.substring(0, sb2.length() - 1)
: "";
写法一通过判断当前长度是否大于零来决定是否加分隔符，逻辑清晰且没有多余操作；写法二代码稍短，但多了一次裁剪。另外要注意，如果集合中可能存在null元素，直接append会出现"null"字面量混进结果的情况，建议在循环里加一层判空处理。这种手写方式的优点是兼容所有JDK版本，缺点是样板代码多，一旦拼接逻辑复杂，可读性会迅速下降。
String.join与StringJoiner的便捷用法
JDK 8引入的String.join静态方法让简单场景的拼接变成了一行代码。它接受一个分隔符和一个Iterable或可变参数，内部实现其实就是借助StringJoiner完成的，性能与手写StringBuilder基本持平，因为StringJoiner底层同样是基于StringBuilder的封装。
List<String> list = Arrays.asList("apple", "banana", "cherry");
// 一行搞定逗号拼接
String result = String.join(",", list); // apple,banana,cherry
// 也可以拼接可变参数
String joined = String.join("-", "2025", "01", "15");
如果需要更灵活的格式控制，比如给整个结果加上前缀和后缀，可以直接使用StringJoiner类。它在构造时分别传入分隔符、前缀和后缀，特别适合拼SQL的in条件这种场景，例如拼出(1,2,3)这样的格式：
List<Integer> ids = Arrays.asList(1, 2, 3);
StringJoiner joiner = new StringJoiner(",", "(", ")");
for (Integer id : ids) {
joiner.add(String.valueOf(id));
}
String inClause = joiner.toString(); // (1,2,3)
需要注意的是，String.join和StringJoiner.add都不允许传入null元素，否则会抛出NullPointerException，这一点比手写循环更严格，使用前最好先做过滤。对于空集合，String.join会返回空字符串，StringJoiner则会返回前缀加后缀的组合（比如上面例子中空集合会得到()），这个行为差异在实际业务中要特别留意。
使用Stream API的collect与Collectors.joining
当集合元素不是String类型，或者拼接前需要过滤、转换时，Stream API配合Collectors.joining是最优雅的方案。它可以在一条链式调用中完成过滤null、类型转换和拼接三件事，代码量少且意图清晰，是JDK 8及以后版本的首选写法。
List<Integer> numbers = Arrays.asList(1, 2, null, 3, 4);
// 过滤null后转字符串再拼接
String result = numbers.stream()
.filter(Objects::nonNull)
.map(String::valueOf)
.collect(Collectors.joining(",")); // 1,2,3,4
// 带前缀后缀的写法
String wrapped = numbers.stream()
.filter(Objects::nonNull)
.map(String::valueOf)
.collect(Collectors.joining(",", "[", "]")); // [1,2,3,4]
从性能角度看，Collectors.joining内部同样使用StringBuilder实现，单次拼接的开销与String.join几乎相同。只有在对同一个集合进行极高频率的拼接时，才需要考虑缓存结果或者改用StringJoiner复用对象。对于绝大多数业务代码而言，这点差异完全可以忽略，优先选择可读性最好的写法。
此外，Stream方式的真正优势在于组合能力。比如集合里装的是对象而不是简单值，你想提取某个字段拼接，配合map就能一步完成：
List<User> users = getUsers();
String names = users.stream()
.filter(u -> u != null && u.getName() != null)
.map(User::getName)
.collect(Collectors.joining(";"));
边界场景与方案选择建议
实际开发中有几个容易踩坑的边界场景值得单独说明。第一是空集合和null集合：String.join处理空集合返回空串，但对null集合会直接抛异常；Collectors.joining对空流同样返回空串，行为比较友好。第二是null元素的处理，前面提到的几种JDK工具类都不接受null，而手写循环如果不判空则会输出null字面量，无论哪种情况，建议在数据入口处就做好清洗。
第三是超大集合的内存问题。无论哪种方式，最终都会生成一个完整的字符串驻留内存，如果集合元素达到百万级别且每个元素较长，需要评估拼接结果的内存占用，必要时考虑分批处理或者直接写入输出流。最后给出一个简单的选择建议：简单字符串列表拼接用String.join；需要前缀后缀用StringJoiner；涉及类型转换、过滤或对象字段提取时用Stream加Collectors.joining；JDK 7及以下的老项目才考虑手写循环。掌握这些方式的特点之后，面对各种集合转字符串的需求就能游刃有余了。
Java集合转换String.joinStream API修改时间：2026-09-11 21:58:37