Logback 1.5.38 发布：一次值得顺手升级的日志框架维护版

预计阅读时间：8 分钟

Logback 1.5.38 已发布。对大多数 Java 服务来说，日志框架平时不显山露水，但它处在异常记录、请求追踪、审计输出这些关键路径上。这个版本的更新点集中在维护和修复，其中提到 HardenedObjectInputStream 中修复了一个与 Throwab... 相关的问题。虽然摘要没有展开完整细节，但仅从组件名称看，它涉及对象输入流的加固逻辑，属于不应长期滞后的基础设施依赖。

Logback 的三个模块各管什么

Logback 继承了 log4j 1.x 的发展脉络，目标是成为其后继者。它不是一个单文件工具库，而是拆成了三个常见模块：

logback-core：基础能力层，包含 appender、encoder、filter 等核心机制。
logback-classic：面向普通 Java 应用的日志实现，也是 SLF4J 绑定最常见的选择。
logback-access：面向访问日志场景，常用于 Web 容器或 HTTP 请求访问记录。

日常 Spring Boot、Micronaut、Quarkus 或普通 JVM 服务里，开发者接触最多的是 logback-classic。它依赖 logback-core，并通过 SLF4J 暴露统一日志 API。也就是说，业务代码通常写的是 LoggerFactory.getLogger(...)，真正落盘、输出 JSON、滚动切分、过滤级别的事情由 Logback 完成。

为什么这个维护版仍然重要

日志框架的问题往往不是“日志少打一行”这么简单。它可能影响：

异常对象如何被记录；
序列化或反序列化路径是否足够保守；
高并发场景下 appender 是否稳定；
访问日志是否能持续输出；
生产环境排障时是否能看到足够可靠的上下文。

本次摘要明确提到 HardenedObjectInputStream 的修复。这个类名本身说明它不是普通的字符串格式化逻辑，而是对象输入流的安全加固相关代码。对于使用远程日志、序列化日志事件、或包含异常对象处理链路的系统，这类修复尤其值得关注。

需要注意的是，摘要没有给出完整问题描述和影响范围，因此不应把它解读成某个确定的安全公告。更稳妥的做法是：把 1.5.38 当作一次低风险维护升级，先在测试环境验证日志格式、滚动策略和异常输出，再进入生产。

可以这样实践：升级依赖并验证日志输出

如果你的项目直接管理 Logback 版本，可以在 Maven 中显式升级。下面示例适用于普通 Java 项目；如果你使用 Spring Boot 的依赖管理，需要确认 Boot 当前管理的 Logback 版本，避免和 BOM 冲突。

<!-- pom.xml：按需替换到你的 dependencyManagement 或 dependencies 中 -->
<properties>
  <logback.version>1.5.38</logback.version>
</properties>

<dependencies>
  <dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>${logback.version}</version>
  </dependency>
</dependencies>

Gradle 项目可以这样写：

// build.gradle
dependencies {
    implementation "ch.qos.logback:logback-classic:1.5.38"
}

为了快速验证升级后日志链路正常，可以准备一个最小 Java 类，检查普通日志和异常日志是否都能输出：

// src/main/java/demo/LogbackSmokeTest.java
package demo;

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

public class LogbackSmokeTest {
    private static final Logger log = LoggerFactory.getLogger(LogbackSmokeTest.class);

    public static void main(String[] args) {
        log.info("logback smoke test started, version check via dependency tree");

        try {
            simulateFailure();
        } catch (RuntimeException ex) {
            log.error("exception logging still works", ex);
        }
    }

    private static void simulateFailure() {
        throw new RuntimeException("sample failure for logback 1.5.38 verification");
    }
}

配一个简单的 logback.xml，确认控制台 appender、pattern 和异常堆栈都符合预期：

<!-- src/main/resources/logback.xml -->
<configuration>
  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n%ex</pattern>
    </encoder>
  </appender>

  <root level="INFO">
    <appender-ref ref="CONSOLE" />
  </root>
</configuration>

运行验证：

mvn -q dependency:tree -Dincludes=ch.qos.logback
mvn -q compile exec:java -Dexec.mainClass=demo.LogbackSmokeTest

如果你没有配置 exec-maven-plugin，也可以先只跑测试或应用启动流程，重点观察三件事：

dependency:tree 中是否只出现一个 Logback 版本；
启动时是否有多个 SLF4J binding 的警告；
异常堆栈是否仍按原格式输出。

升级前后重点看这些地方

Logback 的架构足够通用，这也是它被大量项目采用的原因。但通用也意味着配置形态很多：控制台、文件滚动、异步 appender、JSON encoder、访问日志、按包级别动态调整日志级别。升级时不要只看应用能不能启动。

建议至少检查这些配置：

是否使用 logback-classic 作为唯一 SLF4J 实现；
是否同时引入了旧版 log4j、slf4j-log4j12 或其他桥接包；
RollingFileAppender 的滚动文件名和保留策略是否仍然生效；
异步日志队列是否有丢弃策略；
生产环境是否依赖固定日志格式被采集器解析；
如果使用 logback-access，访问日志字段是否仍和网关、日志平台约定一致。

一个常见的依赖排查命令如下：

mvn dependency:tree \
  -Dincludes=ch.qos.logback,org.slf4j,log4j,org.apache.logging.log4j

看到多个日志实现时，不要急着排除依赖。先确认应用实际需要哪条日志路径：SLF4J 到 Logback、Log4j 到 SLF4J、JUL 到 SLF4J，这些桥接方向一旦搞反，可能出现重复日志甚至循环转发。

采用建议

对普通 Java 服务，Logback 1.5.38 更像是一次“基础设施补丁”而不是功能型升级。推荐的节奏是：先在本地或 CI 中升级，跑启动测试和核心集成测试；再在预发环境观察日志格式、异常堆栈、滚动文件和采集链路；确认没有多绑定和格式漂移后再发布。

如果你的系统涉及序列化日志事件、远程日志传输、复杂异常对象记录，应该更积极地验证这次 HardenedObjectInputStream 相关修复。日志框架不是业务代码的主角，但当线上问题发生时，它就是你能否看清现场的仪表盘。