Java字符串+拼接在编译期仅对常量字面量直接合并为单个字符串，对局部变量则优化为StringBuilder调用；循环中动态拼接不会优化，需显式使用StringBuilder避免性能问题。
Java 中使用 + 运算符拼接字符串时，编译器会在**编译期**自动优化为 StringBuilder（或 StringBuffer）调用，但仅限于**常量字符串拼接**或**局部变量在方法内的一次性拼接**场景；运行时动态拼接（如循环中用 +）则不会自动优化，仍可能频繁创建临时对象。
编译期优化：字符串字面量拼接 → 直接合并为常量
当所有操作数都是编译期可确定的字符串字面量（"a" + "b" + "c"），Javac 直接在 class 文件中生成一个合并后的常量字符串 "abc"，完全不调用 StringBuilder。这是最彻底的优化，发生在编译阶段，与运行时无关。
-
示例：
String s = "Hello" + " " + "World";→ 编译后等价于String s = "Hello World"; - 该优化依赖
String的不可变性和字符串常量池机制
局部变量拼接：编译器插入 StringBuilder 构建逻辑
若拼接涉及局部变量（非 final 或运行时值），且整个表达式出现在**同一个方法体中、无分支/循环干扰**，javac 会将 + 表达式重写为显式的 StringBuilder 调用序列：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
示例：
String s = a + b + c;（a/b/c 是方法参数或局部变量）→ 编译后类似：new StringBuilder().append(a).append(b).append(c).toString() - 注意：只在单条语句内生效；跨多行、带条件判断或循环中的
+不会被统一优化 - 生成的
StringBuilder默认容量为 16，若拼接内容总长超限，会触发数组扩容（代价可测）
运行时陷阱：循环中滥用 + 导致性能暴跌
在 for/while 循环中直接写 s += str，每轮迭代都会新建一个 StringBuilder（或 String 对象），造成 O(n²) 时间复杂度和大量临时对象：
立即学习“Java免费学习笔记（深入）”；
-
反模式：
String result = ""; for (String s : list) result += s;
实际等价于每次循环都执行new StringBuilder(result).append(s).toString() - 正确做法是显式声明
StringBuilder并复用：StringBuilder sb = new StringBuilder(); for (String s : list) sb.append(s); return sb.toString(); - JDK 9+ 对
+=在循环中做了部分 JIT 优化，但不可依赖，手动用StringBuilder更稳定可控
final 局部变量的特殊处理
如果参与拼接的变量是 final 且初始化为常量（如 final String x = "foo";），javac 可能将其视为“事实常量”，进而触发常量折叠优化，甚至绕过 StringBuilder。
- 但该行为属于编译器实现细节，不同 JDK 版本表现可能不同，不建议作为性能依据
- 真正可靠的优化方式仍是：明确场景、避免隐式拼接、关键路径显式使用
StringBuilder
