Logback 1.6.0 已正式发布。这个版本最值得升级者注意的变化，不是新增配置项，而是删除了部分已经弃用的变量、方法和类。对只通过 SLF4J 写日志的应用来说，升级可能相当平稳；但如果项目直接调用 Logback 内部 API、维护自定义 Appender，或者由框架间接引入多个日志实现，编译与启动阶段都可能暴露兼容性问题。
三个模块分别解决什么问题
Logback 延续了 log4j 1.x 的发展脉络，并将能力拆分为三个模块：
logback-core：提供 Appender、Layout、编码器和配置系统等基础设施。logback-classic：实现 SLF4J 后端，是普通 Java 应用最常使用的模块。logback-access：面向 HTTP 访问日志，通常与 Servlet 容器或 Web 服务集成。
大多数业务项目只需直接依赖 logback-classic。它会传递引入匹配的 logback-core，因此不要在没有明确理由时分别指定两个不同版本。logback-access 也不等同于业务代码中的请求日志：只有确实需要容器级访问日志时，才应将它加入依赖。
1.6.0 的升级风险在哪里
来源摘要明确指出，1.6.0 删除了某些已弃用变量、方法和类。这类变化通常会影响三种项目：
- 直接导入
ch.qos.logback.*类型，并在业务代码中操作 LoggerContext、Appender 或配置模型的项目。 - 实现自定义 Appender、Encoder、TurboFilter 等扩展点的基础设施组件。
- 编译时使用一个 Logback 版本，运行时却被应用服务器、插件或依赖管理替换成另一个版本的项目。
如果应用只使用 SLF4J 门面，例如 LoggerFactory.getLogger() 和 logger.info()，业务代码对 Logback 具体 API 的耦合通常较少。不过，这并不能替代依赖树和启动测试：被删除的成员也可能由内部日志组件调用。
由于摘要没有给出完整的移除成员列表，迁移时不要根据类名猜测替代 API。应结合正式发布说明、编译错误和现有扩展点逐项处理。
可以这样实践：建立一个最小升级验证项目
下面示例假设使用 Maven 和 Java 17。若项目采用其他 Java 版本，请修改 maven.compiler.release，并确认它满足 Logback 1.6.0 的实际运行要求。
创建 pom.xml：
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>dev.example</groupId>
<artifactId>logback-160-check</artifactId>
<version>1.0.0</version>
<properties>
<maven.compiler.release>17</maven.compiler.release>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.6.0</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>3.5.0</version>
</plugin>
</plugins>
</build>
</project>
创建 src/main/java/dev/example/App.java：
package dev.example;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public final class App {
private static final Logger log = LoggerFactory.getLogger(App.class);
public static void main(String[] args) {
String orderId = args.length == 0 ? "demo-001" : args[0];
log.info("Starting order processing: orderId={}", orderId);
try {
process(orderId);
log.info("Order processed: orderId={}", orderId);
} catch (RuntimeException ex) {
log.error("Order processing failed: orderId={}", orderId, ex);
}
}
private static void process(String orderId) {
if (orderId.isBlank()) {
throw new IllegalArgumentException("orderId must not be blank");
}
}
}
创建 src/main/resources/logback.xml：
<configuration>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%date{ISO8601} %-5level [%thread] %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="CONSOLE"/>
</root>
</configuration>
运行编译和日志测试：
mvn clean compile
mvn exec:java -Dexec.mainClass=dev.example.App -Dexec.args=order-42
mvn dependency:tree -Dincludes=ch.qos.logback,org.slf4j
最后一条命令尤其重要。正常情况下，依赖树中不应同时出现多个 Logback 版本，也不应存在多个互相竞争的 SLF4J 日志后端。若父 POM 或 BOM 管理了 Logback 版本，应优先在统一的依赖管理位置升级，而不是只在单个模块中覆盖版本。
在真实仓库中定位直接耦合
升级前可以先搜索 Logback 内部 API 的使用位置：
rg -n "import ch\.qos\.logback|ch\.qos\.logback\." \
--glob '*.java' \
--glob '*.kt' \
--glob '*.groovy' .
rg -n "logback-(core|classic|access)|slf4j" \
--glob 'pom.xml' \
--glob '*.gradle' \
--glob '*.gradle.kts' .
搜索结果应分成两类处理：
- 业务类直接依赖 Logback：优先改为 SLF4J API，降低后续更换或升级日志实现的成本。
- 日志基础设施必须依赖 Logback：保留直接依赖，但为自定义 Appender、Encoder 和过滤器增加启动测试与输出断言。
除了编译，还应覆盖配置加载。错误的类名、属性名或扩展组件可能只有在 logback.xml 被解析时才会失败。测试环境最好启动一次完整应用，并检查控制台或文件中是否出现配置解析警告。
升级落地清单
建议按以下顺序推进 Logback 1.6.0：
- 固定
logback-classic、logback-core和相关 SLF4J 依赖的实际解析版本。 - 搜索项目对
ch.qos.logback.*的直接引用，并对照移除成员列表修复。 - 编译所有模块，包括平时不参与主构建的插件、测试工具和运维组件。
- 启动应用，验证
logback.xml或logback-test.xml能被完整解析。 - 检查控制台、滚动文件、异步日志以及异常堆栈是否仍按预期输出。
- 对使用
logback-access的服务单独验证访问日志格式、字段和轮转行为。 - 观察启动日志中是否存在多个 SLF4J Provider、绑定冲突或找不到类的错误。
Logback 1.6.0 的迁移重点是清理历史兼容层。业务代码越坚定地停留在 SLF4J 门面上，升级成本越低；扩展代码越深入 Logback 内部，就越需要依赖树审计、编译验证和真实启动测试共同把关。