Spring Boot Kotlin项目中SLF4J日志：{}与字符串模板哪个更优？

Great question! When working with Logback in a Spring Boot Kotlin project, both the traditional placeholder syntax and Kotlin's string templates have clear tradeoffs. Let's break down which one makes more sense for your use case:

1. Performance: Logback's Placeholders (or Lambda Overloads) Win for Efficiency #

• The Java-style logger.info("Get user paginated: filter {}", user) leverages Logback's core optimization: Logback first checks if the INFO level is enabled for the logger. If it's not (e.g., you're running in debug mode with lower levels active), it skips executing user.toString() entirely—avoiding unnecessary object serialization overhead, especially for complex objects.
• Kotlin's direct string template logger.info("Get user paginated: filter $user") interpolates the string before calling the logger method. This means user.toString() runs every time, even if the log message never gets written to the output. In high-throughput systems or for objects with heavy toString() logic, this can add up to noticeable performance waste.

2. Compatibility with Logback's Advanced Features #

• Placeholder syntax plays nicely with Logback's more powerful capabilities:
  • Structured logging: If you ever switch to structured logging (e.g., JSON output via Logstash encoder), placeholders let you preserve user as a distinct field in the log entry. With string templates, user gets baked into the message string, making it impossible to extract as a separate, queryable field for log analysis.
  • Custom converters: Logback's custom pattern converters (like %replace for masking sensitive data) work seamlessly with placeholder parameters, which isn't the case with pre-interpolated strings.

3. Kotlin Idiomaticity: Use Lambda Overloads for the Best of Both Worlds #

If you love Kotlin's concise syntax but don't want to sacrifice performance or Logback features, use the lambda-based logger overload:

logger.info { "Get user paginated: filter $user" }

This works because Logback's Logger interface has a method that accepts a Supplier<String>. The lambda is only executed if the log level is enabled, so the string interpolation happens lazily—just like the placeholder approach. It's clean, Kotlin-idiomatic, and keeps all of Logback's optimizations intact.

Final Recommendation #

• Prioritize lambda-based logging (logger.info { "... $user" }) for most cases: it's Kotlin-friendly, performant, and compatible with all Logback features.
• Use the placeholder syntax (logger.info("... {}", user)) if you're working with legacy code or prefer the more explicit Java-style pattern.
• Avoid direct string template interpolation (logger.info("... $user")) in performance-sensitive environments or when you might need structured logging later.

内容的提问来源于stack exchange，提问作者CRISTIAN ROMERO MATESANZ