3. 日志门面与绑定机制

在真实 Java 工程里，日志实现往往不止一种：新代码可能用 Logback，老依赖里可能带着 Log4j 1.x、JCL（commons-logging）或 JUL（java.util.logging）。如果每个库都直接调用自己的日志 API，最终会出现多套配置、多个输出目标、重复日志甚至日志丢失。SLF4J 的价值就在于把“写日志的代码”和“日志的实现”解耦：业务代码只依赖 org.slf4j.Logger，运行时再由一个具体绑定决定日志真正写到哪里。

门面、绑定、桥接、适配器四类角色

理解 SLF4J 体系，关键是分清四种角色。第一是门面（Facade）：slf4j-api 只提供接口，如 LoggerFactory.getLogger()、logger.info()，它本身不输出任何日志。第二是绑定（Binding）：把门面接口接到具体实现上，例如 logback-classic 自带 SLF4J 绑定，slf4j-log4j12 把 SLF4J 接到 Log4j 1.2，slf4j-jdk14 接到 JUL。第三是桥接器（Bridge）：把“别的日志 API 的调用”转发到 SLF4J，例如 jcl-over-slf4j 把 JCL 调用桥接到 SLF4J，log4j-over-slf4j 把 Log4j 1.x 调用桥接到 SLF4J，jul-to-slf4j 把 JUL 调用桥接到 SLF4J。第四是适配器（Adapter）：把 SLF4J 的调用转发到某个具体实现，典型如 slf4j-log4j12、slf4j-jdk14、slf4j-simple。桥接器方向是“外部 API → SLF4J”，适配器方向是“SLF4J → 具体实现”，方向相反，不能混用。

绑定冲突是怎么发生的

SLF4J 在类路径上查找绑定，是通过 org.slf4j.impl.StaticLoggerBinder 或 LoggerFactoryBinder 的 SPI 机制完成的。如果类路径上同时出现两个绑定，例如既引入了 logback-classic，又通过某个依赖传递引入了 slf4j-log4j12，启动时就会打印类似下面的警告：

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/.../logback-classic-1.4.14.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/.../slf4j-log4j12-1.7.36.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [ch.qos.logback.classic.util.ContextSelectorStaticBinder]

注意最后一行：SLF4J 会“选一个”绑定，但选择结果依赖类路径顺序，具有不确定性。更危险的是，如果同时存在桥接器和原始实现，例如 jcl-over-slf4j 与 commons-logging 同时存在，JCL 调用可能被桥接器接管，也可能被原始实现接管，导致日志重复或丢失。因此治理原则是：一个应用只保留一个绑定，桥接器与它要替换的原始实现不能共存。

依赖排除实战：以 Maven 为例

假设项目使用 Logback 作为唯一实现，但某个第三方库 legacy-lib 传递引入了 commons-logging 和 log4j。目标是：排除原始实现，引入桥接器，让这些库的日志统一走 SLF4J + Logback。Maven 配置如下：

<dependencies>
  <!-- 门面 -->
  <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.13</version>
  </dependency>

  <!-- 唯一绑定：Logback -->
  <dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.5.6</version>
  </dependency>

  <!-- 桥接器：接管 JCL 与 Log4j 1.x -->
  <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>2.0.13</version>
  </dependency>
  <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>log4j-over-slf4j</artifactId>
    <version>2.0.13</version>
  </dependency>

  <!-- 业务依赖，排除其传递的原始日志实现 -->
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>legacy-lib</artifactId>
    <version>1.0.0</version>
    <exclusions>
      <exclusion>
        <groupId>commons-logging</groupId>
        <artifactId>commons-logging</artifactId>
      </exclusion>
      <exclusion>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
      </exclusion>
      <exclusion>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
</dependencies>

排除后，用 mvn dependency:tree -Dincludes=commons-logging:commons-logging,log4j:log4j,org.slf4j:slf4j-log4j12 验证这些坐标不再出现。如果仍有残留，说明还有别的依赖传递引入，需要继续向上追溯并排除。

桥接器与适配器的选择判断

判断该用桥接器还是适配器，可以看“调用方是谁”。如果调用方是旧日志 API（JCL、Log4j 1.x、JUL），而你想让日志最终走 SLF4J，就用桥接器；如果调用方已经是 SLF4J，而你想让它落到某个具体实现，就用适配器。现代项目通常直接使用 Logback 或 Log4j2，它们自带 SLF4J 绑定，不需要额外适配器；只有需要接管旧 API 时才引入桥接器。

验证与收尾

完成依赖调整后，启动应用观察控制台：不应再出现 “multiple SLF4J bindings” 警告；同一业务操作只应输出一次日志；logback.xml 中配置的 appender 应能同时收到来自旧库和业务代码的日志。若发现某条日志重复，优先检查是否同时存在桥接器和原始实现；若发现某条日志完全消失，检查是否只有 slf4j-api 而没有绑定，或桥接器把日志转发到了未配置的 logger。把“一个绑定、桥接器替换原始实现、排除传递依赖”这三条原则落实到依赖管理里，日志体系才能稳定可控。