StringBuildervs循环翻转字符串方法对比

本文深入剖析了Java中字符串翻转的三种主流方式——StringBuilder.reverse()、手写循环及潜在误区，既强调了new StringBuilder(str).reverse().toString()的安全便捷性，也揭示了直接复用StringBuilder实例调用reverse()引发的隐蔽副作用；同时指出手动实现需严格按码点（而非char）操作以正确支持emoji等Unicode补充字符，并警示了基于String不可变性导致的O(n²)拼接陷阱；内容兼顾实战建议、性能对比与兼容性避坑，是Java开发者处理字符串翻转时不可或缺的精准指南。

用 StringBuilder.reverse() 最省事，但要注意它会修改原对象

多数场景下直接调用 StringBuilder.reverse() 就够了，它底层是原地交换字符数组，时间复杂度 O(n)，没副作用——等等，其实有副作用：reverse() 是就地操作，会改变当前 StringBuilder 实例的内容。

常见错误现象：反复复用同一个 StringBuilder 对象做多次翻转，结果第二次翻转得到的是原字符串（因为第一次已把它翻回去了）。

实操建议：

• 如果只是临时翻一个字符串，写成 new StringBuilder(str).reverse().toString()，安全又清晰
• 避免对长期持有的 StringBuilder 实例频繁调用 reverse()，除非你明确需要它被修改
• 注意 StringBuilder 和 StringBuffer 的 reverse() 行为一致，但后者线程安全、性能略低，单线程别用 StringBuffer

手写循环翻转时，别从 0 到 length() 全遍历

自己用 for 循环翻转字符串，核心是首尾交换，只需遍历一半长度。写成 i 是典型越界或逻辑错乱的源头。

使用场景：需要控制翻转粒度（比如只翻转某段子串）、或教学/面试中考察基础功底。

实操建议：

• 正确边界是 i ，整数除法天然向下取整，对奇偶长度都安全
• 用 toCharArray() 转数组再交换，比反复调用 String.charAt() + 拼接快得多（后者每次 + 都新建对象）
• 别在循环里用 String.substring() 拼接，那是 O(n²) 的写法

简短示例：

char[] cs = str.toCharArray();
for (int i = 0; i     char tmp = cs[i];
    cs[i] = cs[cs.length - 1 - i];
    cs[cs.length - 1 - i] = tmp;
}
return new String(cs);

性能差得明显的情况：用 String.concat() 或 + 在循环里拼接

有人试图用 for 从后往前取字符，再用 += 累加，结果在长字符串下慢出天际。这不是“写法不同”，是算法复杂度跳变。

原因：Java 中 String 不可变，每次 + 都新建对象，n 次拼接总耗时接近 O(n²)；而 StringBuilder 是可变的，追加是均摊 O(1)。

实操建议：

• 只要涉及多次字符串拼接，无条件优先用 StringBuilder（哪怕只拼两次）
• String.concat() 比 + 略快但仍是不可变操作，别指望它能救循环拼接
• JDK 9+ 的字符串压缩（compact strings）对翻转没影响，不用额外考虑

Unicode 补充字符会让所有基于 char 的翻转出错

遇到 emoji 或某些生僻汉字（如 U+1F600 ?、U+20000 ?），它们占两个 char（即一个代理对），但 char 是 16 位，无法单独表示。此时按 char 翻转，会把代理对拆开，产生乱码。

这是最容易被忽略的兼容性坑——本地测试用英文和普通中文全好，上线后用户一发 ? 就崩。

实操建议：

• 用 String.codePointAt() 和 Character.toChars() 处理 Unicode 码点，而不是 charAt()
• StringBuilder.reverse() 在 JDK 9+ 已修复此问题，它内部按码点而非 char 处理
• 手写循环时，必须用 String.offsetByCodePoints() 计算索引，不能简单用 i++

事情说清了就结束

好了，本文到此结束，带大家了解了《StringBuildervs循环翻转字符串方法对比》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！