为什么用Logback不用Log4j？

数据不会说谎，尤其是异步日志，Logback 的性能几乎是 Log4j 的 3 倍多，差距非常明显。

二、核心原因 2：原生兼容 SLF4J，避免日志冲突

做 Java 开发的都知道，日志框架的“冲突”是个让人头疼的问题。

很多第三方依赖（比如 Spring、MyBatis）都会自带日志框架，有的用 Log4j，有的用 JUL（Java 自带日志），如果项目中自己用的是另一种，就会出现依赖冲突，导致日志打印异常、启动失败。

这时候，SLF4J（简单日志门面）就出现了——它相当于一个“日志中间层”，定义了统一的日志接口，不管底层用的是 Log4j、Logback 还是其他框架，都能通过 SLF4J 调用，避免冲突。

而 Logback 是 原生支持 SLF4J 的，不需要额外引入依赖，直接就能和 SLF4J 集成，开发时只需要调用 SLF4J 的 API，底层由 Logback 实现，非常简洁。

反观 Log4j，它本身不支持 SLF4J，想要集成的话，必须额外引入 log4j-over-slf4j.jar 这个适配包，而且还可能出现适配不兼容的问题。我之前就踩过这个坑，引入适配包后，部分日志无法正常打印，排查了半天才找到原因。

举个简单的例子，同样是打印日志，用 SLF4J+Logback，代码是这样的（简洁无冗余）：

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Demo {
    private static final Logger logger = LoggerFactory.getLogger(Demo.class);
    
    public static void main(String[] args) {
        logger.info("这是一条日志");
    }
}

而如果用 Log4j，要么直接调用 Log4j 的 API（耦合度高），要么引入适配包，操作繁琐，还容易出问题。

三、核心原因 3：配置简单，功能更强大，还能动态调整

Log4j 的配置文件（log4j.properties）虽然简单，但功能比较基础，想要实现一些复杂的需求（比如按日期拆分日志、按级别过滤日志、动态调整日志级别），需要写大量的配置，而且不够灵活。

Logback 则弥补了这些不足，它支持两种配置方式：XML（logback.xml）和 Groovy（logback.groovy），配置更简洁，功能也更强大。

举几个实际开发中常用的功能，Logback 做起来更轻松：

1. 日志拆分更灵活

日常开发中，我们需要按日期拆分日志（比如每天一个日志文件），避免单个日志文件过大，方便排查问题。

Log4j 实现按日期拆分，需要配置 RollingFileAppender，还要写复杂的日期格式配置，而且拆分后的日志文件名不够规范。

而 Logback 只需要配置 TimeBasedRollingPolicy，几行配置就能实现按天、按小时拆分，还能设置日志文件的保留时间、最大大小，非常灵活：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <file>logs/demo.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>logs/demo.%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>30</maxHistory> <!-- 保留 30 天日志 -->
    </rollingPolicy>
    <encoder>
        <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern>
    </encoder>
</appender>

2. 动态调整日志级别，不用重启服务

这是 Logback 一个非常实用的功能，也是 Log4j 不具备的。

生产环境中，有时候需要排查问题，需要临时调高日志级别（比如从 INFO 调到 DEBUG），但 Log4j 必须重启服务才能生效，这在高可用的生产环境中是不可接受的（重启会导致服务中断）。

而 Logback 支持动态调整日志级别，不需要重启服务，只需要修改配置文件，或者通过 JMX 远程调整，就能实时生效。比如，我之前在生产环境排查一个偶发 bug，通过动态调整日志级别，快速定位到问题，没有影响服务正常运行。

3. 内置日志过滤功能

开发中，我们经常会遇到一些不需要的日志（比如第三方依赖的 debug 日志），这些日志会占用磁盘空间，还会干扰我们排查问题。

Logback 内置了强大的日志过滤功能，可以按日志级别、包名、日志内容过滤，只保留我们需要的日志。比如，过滤掉 org.springframework 包下的 DEBUG 级别日志，只需要添加几行配置：

<logger name="org.springframework" level="INFO" additivity="false">
    <appender-ref ref="FILE" />
</logger>

而 Log4j 想要实现类似的功能，需要自定义过滤器，代码繁琐，还容易出错。

四、核心原因 4：维护活跃，无安全漏洞，更靠谱

对于生产环境来说，框架的维护活跃度和安全性，比什么都重要。

Log4j 1.x 已经 停止维护 很多年了，官方不再更新，也不再修复已知的漏洞。这意味着，一旦 Log4j 出现安全漏洞（比如之前的 Log4j 漏洞风波，虽然主要影响 Log4j2，但 Log4j 1.x 也有潜在风险），我们无法获得官方修复，只能自己手动修复，风险极高。

而 Logback 一直保持着活跃的维护，官方会定期更新，修复漏洞、优化性能，而且它的作者就是 SLF4J 的作者，兼容性和稳定性更有保障。

另外，Logback 的社区也非常活跃，遇到问题，很容易在网上找到解决方案，而 Log4j 因为停止维护，很多问题已经找不到相关的解决思路了。

五、常见疑问：Log4j2 比 Logback 好吗？为什么不选 Log4j2？

很多人会问，Log4j2 是 Log4j 的升级版，性能也很好，为什么不直接选 Log4j2，反而选 Logback？

我的答案是：Log4j2 确实优秀，但对于大部分中小项目来说，Logback 已经足够用了，而且更稳妥。

Log4j2 的性能和功能都很强大，甚至比 Logback 更优，但它也有一个明显的缺点：配置复杂，学习成本高，而且和部分老项目的兼容性不够好，容易出现依赖冲突。

比如，Log4j2 的配置文件（log4j2.xml）比 Logback 的配置更复杂，尤其是异步日志、自定义插件的配置，新手很难快速上手。而且，Log4j2 的依赖包比 Logback 多，引入后会增加项目的体积，对于微服务项目来说，不够轻量化。

总结一下：

• 中小项目、快速开发、追求稳定性和易用性：选 Logback，没错。
• 超大规模项目、高并发场景、追求极致性能：可以考虑 Log4j2，但需要投入更多的学习和维护成本。

六、总结：别再纠结，Logback 就是最优解（对大部分开发者而言）

结合我多年的项目经验，总结一下为什么优先选 Logback，不选 Log4j：

1. 性能更优：尤其是异步日志，碾压 Log4j，高并发下不拖慢系统。
2. 原生兼容 SLF4J：避免日志依赖冲突，开发更简洁。
3. 配置简单、功能强大：支持动态调级、灵活拆分日志，满足日常开发所有需求。
4. 维护活跃、安全可靠：官方持续更新，无停止维护风险，漏洞能及时修复。

其实，日志框架的选型没有绝对的“最好”，只有“最适合”。但对于 90%的 Java 开发者（尤其是中小项目、新手）来说，Logback 就是最稳妥、最省心的选择。

如果你现在项目还在用 Log4j，建议尽快迁移到 Logback，迁移成本很低（几乎不需要修改业务代码，只需要替换依赖和配置文件），但能带来明显的性能和稳定性提升。