应使用局部stringbuilder而非stringbuffer拼接日志，因其无锁高效且作用域清晰；敏感信息须脱敏，优先采用日志框架占位符机制，避免全局复用和用户输入直拼引发泄露或注入。
在Web应用中用StringBuffer拼接日志，安全性本身不是问题，但“是否该用StringBuffer”才是关键点。
StringBuffer的线程安全不等于日志场景天然适用
StringBuffer所有方法都加了synchronized，确实能保证多线程并发调用append时不会出现数组越界或长度错乱。但这只解决“对象内部状态一致性”问题，并不解决日志拼接中更实际的风险：
- 日志内容含用户输入（如请求参数、header）时，未过滤直接拼入，可能引发敏感信息泄露或日志注入（例如换行符伪造日志条目）
- 日志对象被长期持有并跨请求复用，容易造成不同请求日志混杂（比如把用户A的token拼进用户B的日志里）
- 同步开销在高并发日志写入路径上反而成为瓶颈，尤其当多个线程频繁争抢同一StringBuffer实例锁时
Web日志拼接的常见错误用法
典型反模式是定义一个static StringBuffer作为全局日志缓冲区：
- 所有请求共用同一个实例 → 线程安全虽有保障，但日志内容交叉污染不可避免
- 为“避免创建对象”而复用 → 忽略了局部StringBuilder+toString()的开销远低于锁竞争成本
- 在Filter或Interceptor中提前初始化StringBuffer，再一路传递 → 增加上下文耦合，破坏单次请求边界
更合理的选择和做法
现代Web应用中，日志拼接几乎不需要StringBuffer：
- 单次请求内拼日志，一律用局部StringBuilder（无锁、快、作用域清晰）
- 需异步写日志时，用Log4j2/Logback等框架的占位符机制（如
logger.info("User {} accessed {}", userId, path)），格式化延迟到日志器真正输出前，且线程安全由框架保障 - 若真要手动拼接多线程共享的日志内容（极少见），优先考虑无锁方案：用ThreadLocal
隔离，或用不可变字符串+原子引用（如AtomicReference ）做最终合并
真正该关注的安全细节
比起选StringBuffer还是StringBuilder，以下几点对日志安全影响更大：
- 敏感字段（密码、token、身份证号）必须脱敏后再拼入日志，不能依赖“不打印”配置
- 避免把完整异常堆栈直接拼进业务日志（易含内部路径、类名、配置片段），应提取关键信息
- 日志输出目标（文件、网络、ELK）本身要有访问控制，防止未授权读取
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
