简介

痛点：在项目中直接使用具体日志实现，会导致后期换框架、统一日志格式还有与第三方库的兼容性问题。

SLF4J 是 Java 里很常见的日志门面。

门面这两个字听起来有点抽象。放到日志里理解就很简单：业务代码只调用 SLF4J 的 API，真正写日志的工作交给 Logback、Log4j2、JDK Logging 这类日志实现。

说白了代码里写的是：

log.info;其实，

至于这条日志最终输出到控制台、文件、Kafka、ELK。还是按天滚动保存，属于日志实现和配置文件要处理的事情。

SLF4J 的价值主要在于解耦。

业务代码不用直接绑定某一个日志框架，依赖库也不用强迫应用使用某一个日志实现。应用最终选择一个日志实现即可，比如 Spring Boot 默认常用的 Logback。话说回来，

关系

痛点：开发者经常混淆“门面”和“实现”。导致依赖冲突或运行时找不到 Provider。

A typical call chain looks like this:

业务代码 -> SLF4J API -> Logback / Log4j2 / JUL 等日志实现 -> 控制台、文件、日志程序

SLF4J 只定义怎么调用日志，Logback 这类实现负责格式化、级别控制、文件滚动、异步输出等具体行为。不过，

.x 与 .x 的关键变化

.x 时代经常能看到 b binding a 词。比如 slf4j-log4j12,logback-classic a。.x 以后官方更强调 provider 机制，底层基于 Java 的 S erviceLoader a 查找提供者。

If only s lf4 j-api a present without a provider,program starts but no logs are output;console usually warns “No SLF4J providers were found”. Therefore dependencies must be split into two layers:

slf4j-api // 日志 API
logback-classic // 日志实现

普通 Java 项目怎么引入

1.7.36
1.2.11



org.slf4j
slf4j-api
${slf4j.version}


ch.qos.logback
logback-classic
${logback.version}

`slf4j-api` 提供 `Logger`、`LoggerFactory` 接口；`logback-classic` 才是真正落地的实现。 没有它们，即使调用了 API，也看不到任何输出。

Spring Boot 项目还要单独加吗？

`spring-boot-starter-web` 已经间接带上 `spring-boot-starter-logging → logback-classic → slf4j-api`。大多数 Spring Boot 项目不需要手动添加这些依赖。

If you want to switch from Logback to Log4j2,you **don’t** add anor implementation on top of existing one. Instead。exclude default starter and add `spring-boot-starter-log4j2`.

最小可运行 Demo

package com.example.logdemo;import org.slf4j.Logger;怎么说呢，import org.slf4j.LoggerFactory;说起来，public class OrderService {
private static final Logger log = LoggerFactory.getLogger;public void createOrder {
log.info;long orderId = System.currentTimeMillis;log.info，}
public static void main {
new OrderService.createOrder;}
}

The output format is defined by Logback configuration,not by SLF4J.

日志级别怎么选？

`INFO/WARN/ERROR` 是生产环境的主力；其实，`DEBUG` 在排查问题时打开即可；过多 `TRACE` 会把磁盘占满并拖慢程序。

占位符写法

log.info;