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

本文深入剖析了Java中字符串翻转的三种主流方式——StringBuilder.reverse()、手写循环翻转和错误拼接实践，既揭示了看似便捷的StringBuilder.reverse()隐藏的副作用（原地修改导致复用陷阱），也指出了手写翻转时遍历长度、索引计算和Unicode兼容性（特别是emoji等补充字符）等关键细节，并通过性能对比明确指出：盲目使用String+拼接或substring循环是O(n²)级灾难，而正确使用StringBuilder或基于码点的手写翻转才能兼顾效率与健壮性，尤其在真实业务场景中，一个未考虑代理对的翻转可能让系统在用户输入emoji时悄然崩溃。

用 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学习网公众号吧！