在java项目中统一日志框架的核心做法是引入一个桥接层，将旧有依赖（如log4j、jcl）的调用重定向到目标框架（如slf4j+logback），并通过maven或gradle排除冲突的传递性依赖。具体操作是在构建文件中声明目标日志实现，同时使用`slf4j-log4j12`等适配器包接管遗留代码的输出，确保所有模块最终都通过同一个门面接口进行日志记录。
如何排除传递性日志依赖
要解决日志冲突，必须从根源上切断其他日志实现的引入。在Maven中，可以通过`
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
上述配置排除了Spring Boot默认的日志启动器。接下来需要显式引入Log4j2的启动器，这样项目中所有的日志调用都会指向Log4j2的实现。这种“先排除后引入”的模式是统一日志框架的标准流程，能有效防止因版本差异导致的类加载错误。
立即学习“Java免费学习笔记（深入）”；
如何将旧日志实现桥接到新框架
对于无法立即重构代码的老项目，直接替换日志API是不现实的。此时应使用桥接器（Bridge）将旧的日志实现转换为新框架的调用。以Log4j 1.2为例，可以使用`log4j-over-slf4j`包。这个包提供了与Log4j 1.2相同的类名和方法签名，但在内部会将日志请求转发给SLF4J。这样，原有的`Logger.getLogger()`调用就会自动路由到SLF4J绑定的实现上，无需修改业务代码中的日志语句。
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.36</version>
</dependency>
引入该依赖后，任何使用Log4j 1.2 API的代码都会通过桥接层输出到SLF4J配置的目的地。需要注意的是，必须确保类路径中不存在原始的`log4j` jar包，否则会出现递归调用或优先级冲突。通常建议同时排除原始Log4j依赖，只保留桥接包和SLF4J实现。
统一后日志输出的实际表现是什么
完成统一配置后，项目的日志输出行为会完全由目标框架的配置决定。例如，若统一为Logback，则所有日志格式、级别过滤和文件滚动策略都由`logback.xml`控制。无论代码最初使用的是哪种日志API，最终生成的日志行都将遵循统一的模板。这简化了运维工作，因为只需维护一份配置文件即可管理整个应用的日志行为，且能确保不同模块的日志时间戳和格式保持一致，便于后续的分析工具解析。
