核心目的是避免日志级别禁用时的无谓字符串拼接：占位符{}通过isDebugEnabled()预检，仅在启用时才执行参数求值与格式化，杜绝无效toString()、对象创建及GC开销；而+拼接无论级别是否启用均强制执行，造成3–10倍性能损耗。
Java 中用 SLF4J（如 Logback）日志框架时，用 {} 占位符拼接字符串，核心目的是避免在日志级别被禁用（比如 DEBUG 关闭）时，仍执行字符串拼接操作——这能显著减少无意义的字符串创建、GC 压力和 CPU 消耗。
为什么不用字符串拼接（+）？
直接写 log.debug("user id: " + userId + ", name: " + userName) 会导致：即使当前日志级别是 INFO（DEBUG 不生效），userId + userName 的拼接依然执行，对象创建、StringBuilder 扩容、toString() 调用全白做。高频 debug 日志下，性能损耗明显。
占位符 {} 是怎么工作的？
SLF4J 的 log.debug("user id: {}, name: {}", userId, userName) 会先判断当前日志级别是否允许输出 DEBUG。只有通过判断后，才把参数依次填入模板，真正执行字符串格式化。否则，参数对象仅被传入，不触发 toString() 或拼接逻辑。
- 参数是 null？不会 NPE，占位符显示为
"null" - 参数是复杂对象？仅当真要打印时才调用其
toString() - 支持最多 3 个参数的快捷方法（
debug(String, Object, Object, Object)），更多参数自动回退到可变长参数重载（略有额外数组开销，但远小于无谓拼接）
哪些情况仍可能踩坑？
占位符只保护“参数计算”本身，不保护参数生成过程：
立即学习“Java免费学习笔记（深入）”；
- ❌ 错误：
log.debug("data: {}", toJson(obj))——toJson()总会执行，哪怕 DEBUG 关闭 - ✅ 正确：
log.debug("data: {}", () -> toJson(obj))（需 SLF4J 2.0+ 支持 lambda 延迟求值） - ✅ 兼容方案：
if (log.isDebugEnabled()) { log.debug("data: {}", toJson(obj)); }
进阶建议：统一规范 & 工具辅助
团队中可制定日志规范，禁止在日志参数位置写表达式；CI 阶段用 SpotBugs 或自定义 Checkstyle 规则检测 log.debug("..." + ...) 模式；IDEA 中启用 “SLF4J logging statements with string concatenation” 检查提示。
