StringBuffer 的线程安全仅在多线程共享同一实例并并发调用修改方法时有效，适用场景需同时满足共享、并发写、无法规避共享及顺序敏感；否则应优先使用 StringBuilder 或不可变方案。
不适用。
StringBuffer 的线程安全只在一种前提下真正起作用：多个线程共享同一个 StringBuffer 实例，并且同时调用它的修改方法（如 append、insert、delete）。它不是“多线程环境就自动适用”，而是有明确的使用边界。
适用的场景需同时满足：
- 多个线程共用一个 StringBuffer 对象（非局部变量、非 ThreadLocal 封装）
- 这些线程会并发调用写操作方法
- 无法通过设计规避共享（比如改用局部 StringBuilder、String.join、Stream.collect 等不可变方式）
- 结果正确性依赖操作顺序（例如日志拼接不能错位、响应头不能截断）
不适用或不应使用的常见情况：
立即学习“Java免费学习笔记（深入）”；
- 每个线程都 new 自己的 StringBuffer：此时同步毫无意义，反而拖慢单线程性能
- 字符串操作发生在方法内部，变量生命周期限于当前线程：天然隔离，用 StringBuilder 更高效
- 只读操作居多（如反复调用 toString() 或 length()）：StringBuffer 的同步锁仍会被触发，但无实际保护价值
- 高并发细粒度拼接（如每毫秒上百次 append）：锁竞争严重，吞吐量骤降，应改用队列+批量处理或异步日志框架
容易被误认为“需要”但实际不需要的情况：
- Web 应用中每个 HTTP 请求拼接 SQL 或 JSON：请求线程彼此独立，用局部 StringBuilder 即可
- 使用 ThreadLocal 包裹 StringBuffer：已实现线程隔离，换成 StringBuilder + ThreadLocal 更轻量
- 最终只需合并结果（如各线程生成片段后汇总）：让每个线程用 StringBuilder，最后用 String.join 或 StringBuffer.collect 统一拼接
它的线程安全是真实的，但只是“兜底方案”，不是通用解法。现代 Java 开发中，绝大多数字符串拼接都应优先考虑不可变、局部化、无共享的设计。
