concat()仅接受String类型参数，不自动转换、不处理null，性能与+无显著差异；+支持隐式转换和null转"null"，编译期优化字面量拼接，底层用StringBuilder。
concat() 不能拼非 String 类型，编译直接报错
如果你写 "a".concat(123)，Java 编译器会拒绝——concat() 只接受 String 类型参数。它不自动调用 toString()，也不做任何类型转换。你得手动转：比如 "a".concat(String.valueOf(123)) 或 "a".concat("" + 123)。
而 + 运算符只要一边是 String，另一边就会隐式调用 toString()："a" + 123、"a" + true、"a" + null 全部合法，且不会编译失败。
-
concat()是强类型约束，适合需要显式控制输入类型的场景 - 用
+更省事，但可能掩盖类型误用（比如本该是int却传了Integer包装类，你还察觉不到）
concat() 遇到 null 就抛 NullPointerException
"a".concat(null) 运行时立刻炸，堆栈里清清楚楚写着 NullPointerException。它不做空值防御，也不给你兜底。
而 "a" + null 会安静地变成 "anull"——因为 + 底层把 null 当作字符串对象调用了 String.valueOf(null)，返回字面量 "null"。
- 如果你的参数来源不可靠（比如 Map.get(key) 可能为 null），用
concat()就得先判空，否则线上崩 - 用
+虽然不崩，但可能把 bug 隐藏成诡异的业务逻辑错误（比如用户名显示成"usernull"）
单次两字符串拼接，concat() 略快但差别微乎其微
从字节码和源码看，concat() 直接操作字符数组，拷贝一次；+ 在编译期会被转成 StringBuilder.append().toString()，多一层对象创建开销。但这个差距在单次或少量拼接中几乎测不出来。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
真正要注意的是链式调用：s.concat("a").concat("b").concat("c") 每次都新建 String，共生成 3 个中间对象；而 s + "a" + "b" + "c" 编译后通常只用一个 StringBuilder，实际更省。
- 不要为了“理论上快一点”硬套
concat()，尤其在链式或循环里 - 如果只是拼两个已知非 null 的字面量或变量，
concat()和+性能可视为等价
编译期常量拼接，+ 会被优化，concat() 不会
像 "hello" + "world" 这种纯字面量拼接，javac 直接合成一个常量 "helloworld"，运行时不产生额外对象；但 "hello".concat("world") 仍会在运行时执行数组拷贝，新建 String 实例。
这意味着：如果你写的是静态拼接（比如日志前缀、SQL 片段），用 + 反而更轻量；而 concat() 在这种场景下毫无优势，还多一次方法调用。
- 编译期优化只认字面量 + 字面量，变量一掺和就失效
-
concat()没有编译期优化路径，永远走运行时逻辑
真正容易被忽略的是：很多人以为 concat() 是 + 的“底层实现”，其实不是。+ 编译后走 StringBuilder，而 concat() 是独立的数组拷贝逻辑——它们根本不在一条执行路径上。选哪个，得看你要的是类型安全、空值敏感，还是写起来顺手。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
