SpringBoot日志架构详解：SLF4J绑定、桥接与依赖冲突排查

你有没有遇到过这样一种情况：SpringBoot项目本来跑得好好的，加了一个第三方依赖之后，控制台突然冒出“SLF4J: Class path contains multiple SLF4J bindings”的警告，或者更离谱——日志格式变成了两套，一套是SpringBoot默认的彩色日志，另一套是Log4j那种纯文本WARN。我刚干SpringBoot那阵子第一次撞见这个，整整折腾了一个下午。后来把SLF4J在SpringBoot里的角色想明白了，才发现日志这块其实有一条非常清晰的架构线，大部分诡异问题都是因为“绑定”和“桥接”这两个环节出了岔子。

这篇文章不打算照着SDK文档复读，而是把SpringBoot中SLF4J从门面机制、自动装配绑定、配置落地、依赖冲突排查到生产环境实践这条完整链路拆开讲。无论你是刚接触SpringBoot的初学者，还是被日志问题折磨过一两回的老手，都能在文章里找到对应自己场景的那部分内容。看完之后，你至少能弄清楚三件事：SLF4J到底在项目里扮演什么角色、SpringBoot是怎么把日志框架自动“装配”进来的、以及那些让人头大的日志依赖冲突该怎么一步步查根因。

1. 从一次“日志打印错乱”事故说起：SLF4J在项目里的真实身份

1.1 那次事故的现场

事情是这样的：我们的支付模块引入了一个老牌的HTTP客户端库，这个库是好几年前写的，内部用的是Log4j 1.x的API。SpringBoot默认接的是Logback，两者本身井水不犯河水，但问题在于——这个库把Log4j的实现包也带进了classpath。

结果就是，项目启动后控制台出现两条并行的日志线：SpringBoot自己的业务日志还是按logback-spring.xml里的pattern输出，但那个第三方库的日志却走的是Log4j的默认配置，格式完全错乱，而且它内部的ERROR信息经常被截断，因为没有给它配置appender。更麻烦的是，它的日志里混进了log4j:WARN No appenders could be found for logger这类提示，看着像项目要崩了，其实只是日志框架没匹配上。

这个问题的本质，就是不同日志API之间的“语言不通”。

1.2 门面模式：SLF4J是那根名叫“统一标准”的USB线

要理解SLF4J，先把它和“门面模式”这个概念绑在一起。门面模式的核心思想是：对外提供一个统一、简洁的接口，内部隐藏具体实现细节。SLF4J全称Simple Logging Facade for Java，就是所有Java日志框架前面那层统一的“脸”。

代码里你只需要依赖slf4j-api，写这样的代码：

import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class OrderService { private static final Logger log = LoggerFactory.getLogger(OrderService.class); public void createOrder() { log.info("create order start, userId: {}", userId); } }

这里的Logger和LoggerFactory都来自slf4j-api，它本身不干任何日志输出的活。真正把日志写到控制台、写进文件的，是底层的Logback或Log4j2。SLF4J做的事情，就是把你调的info、debug、error这几个方法，翻译成底层框架能听懂的话。

你可以把它类比成USB接口：SLF4J是那个Type-C接口标准，Logback、Log4j2、JUL都是不同的设备。不管接口后面连的是什么设备，你插的那一端长得都一样。正是这层“统一”，让你今天用Logback，明天想换Log4j2，业务代码一行都不用改，只需要调整依赖和配置文件。

1.3 为什么SpringBoot选SLF4J而不是直接绑Logback

这里有个很自然的疑问：既然SpringBoot默认组合就是SLF4J+Logback，为什么不干脆直接用Logback的API，岂不是少了一层弯路？

因为SpringBoot要考虑的不是自己，而是整个生态。一个实际项目里，Spring框架本身、Hibernate、MyBatis、各种第三方SDK，它们依赖的日志API各不相同：有的用commons-logging（JCL）、有的用Log4j、有的用java.util.logging。如果SpringBoot强制大家都用Logback API，那第三方库的日志就全“哑”了。

这时候SLF4J的价值就出来了：它提供了一个中间层，可以把JCL、Log4j、JUL的调用全部桥接到SLF4J API上，再统一路由到Logback。于是整个项目无论来源多杂，日志最终只会走一条路。SpringBoot选用SLF4J还有一个现实原因：SLF4J和Logback是同一个作者（Ceki Gülcü），两者在版本兼容和功能配合上天然顺滑。SpringBoot官方文档里也明确写了：默认使用SLF4J作为门面、Logback作为实现。

2. SpringBoot自动装配背后的日志绑定链条

2.1 spring-boot-starter-logging里都装了哪些包

你做SpringBoot项目时，几乎不需要手动引入日志依赖，因为在spring-boot-starter-web这类常用starter里，已经间接包含了spring-boot-starter-logging。这个starter体积很小，但里面的内容就是整个日志机制的核心。

用mvn dependency:tree查看，你会看到它内部包含这样几个关键包：

• logback-classic：Logback的核心实现，最终负责把日志写出去。
• logback-core：Logback的底层支持库。
• slf4j-api：SLF4J门面接口，所有LoggerFactory都从这里来。
• log4j-to-slf4j：把Log4j2的API调用桥接到SLF4J的适配器。
• jul-to-slf4j：把java.util.logging的调用桥接到SLF4J的适配器。

你看这个清单，会注意到它刻意把各种日志API都“拉拢”到了SLF4J这层。这样不管项目里哪个第三方组件用的是Log4j2还是JUL，最终都会被引导到Logback这条统一输出链路上来。

这里要特别提一句：starter里没有包含jcl-over-slf4j，因为Spring 5之后自己实现了spring-jcl，它在API层面兼容commons-logging，内部会自动探测并用SLF4J作为真实实现。所以Spring框架的日志天然就统一到了SLF4J上。

2.2 绑定、桥接、适配：三组容易混淆的jar

把SLF4J和相关日志包的关系理清楚，是排查日志问题的基础。我把它们分成了三类，分别解释：

第一类是绑定包，解决“SLF4J接口由谁实现”的问题。SLF4J本身不干活，总得有个具体框架接住调用。绑定的方式有两种：一种是原生绑定，比如logback-classic直接在内部实现了SLF4J对应的接口，加依赖就能用；另一种是适配绑定，比如log4j-slf4j-impl（对应SLF4J 1.7版本）或log4j-slf4j2-impl（对应SLF4J 2.x版本），它把SLF4J的接口翻译成Log4j2的API调用。前者是Logback自带的接口转账功能，后者是靠一个翻译层和Log4j2对接。

第二类是桥接包，解决“别人的日志API怎么接到SLF4J上”的问题。典型的有log4j-over-slf4j（把Log4j 1.x的调用桥接到SLF4J）、jcl-over-slf4j（把commons-logging的调用桥接到SLF4J）、jul-to-slf4j（把java.util.logging的调用桥接到SLF4J）。它们的原理就是：替换掉原日志框架的类库，让你原来调用Log4j的代码实际调用到SLF4J API上。

第三类是“反向”桥接包，解决“SLF4J调用如何落到其他框架”的问题。比如你坚持用Log4j2作为底层实现，就需要log4j-slf4j-impl这样的包。

我用一张表把这几个容易混淆的包放在一起对比：

这些包如果放错了或者重复了，就会出现开篇那种日志错乱的现象。我见过的典型错误是：项目里同时引了logback-classic和log4j-slf4j-impl，等于一个接口被两个实现同时响应，SLF4J只能发出警告并随机选一个，结果日志行为完全不可预期。

2.3 从一条启动日志看日志系统初始化顺序

SpringBoot对日志的初始化不是靠什么魔法，而是由一个专门的监听器完成的。在SpringBoot 2.x里，这个角色是LoggingApplicationListener；到了3.x，变成了LoggingSystemFactory配合对应的LoggingSystem实现。

它处理的时机在Spring容器启动早期、环境变量准备好之后。整个流程大致是这样的：

1. 应用启动，监听器捕获到ApplicationEnvironmentPreparedEvent事件。
2. 读取application.yml或application.properties中的logging.*配置。
3. 根据classpath里存在的日志框架，确定使用哪种LoggingSystem。
4. 寻找配置文件，优先级从高到低：logback-test.xml、logback.xml、logback-spring.xml。SpringBoot官方推荐的logback-spring.xml反而排在最后，因为它允许使用SpringBoot的扩展标签，需要SpringBoot介入处理，如果找不到就使用SpringBoot内置的默认配置。
5. 把application.yml里的logging.level、logging.pattern等配置覆盖到已加载的日志配置上。

这里有个容易忽略的细节：application.yml里的logging配置，会在logback.xml加载完成后做一次覆盖。也就是说，哪怕你的logback.xml里写了root的level为DEBUG，只要application.yml里logging.level.root=INFO，最终生效的仍然是INFO。这个覆盖顺序在实际项目中帮了我不少忙，因为换环境调日志级别时，不用频繁改XML，直接改配置就行。

3. 实际配置：从application.yml到logback-spring.xml

3.1 application.yml中的logging配置项

日常开发中，日志级别调整是最高频的操作。多数情况用application.yml就能解决，不需要动XML。下面这份是我在项目中常用的配置模板：

logging: level: root: INFO com.example: DEBUG org.springframework.web: WARN org.apache.kafka: WARN file: name: ./logs/app.log pattern: console: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n" file: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n" logback: rollingpolicy: max-file-size: 100MB max-history: 30 file-name-pattern: ./logs/app.%d{yyyy-MM-dd}.%i.log

逐个解释一下：logging.level.root控制全局日志级别，logging.level.com.example则可以为某个包单独设置级别，这在实际排查问题时非常有用，可以针对业务包开DEBUG，其他保持INFO。logging.file.name指定日志输出文件，注意如果只配置file.path，则只生成spring.log文件，想要固定文件名用name更直观。pattern部分是对输出格式的微调。rollingpolicy是SpringBoot对Logback滚动策略的简化配置，文件超过100MB就自动切换，保留最近30天。

这套配置的优点是：不写XML也能满足70%的场景。如果你的项目日志结构不复杂、不需要多环境差异化处理，完全可以一条yaml走天下。

3.2 logback-spring.xml模板与多环境开关

当需要细粒度控制appender、过滤器或按环境切换时，就得动用logback的XML配置。这里有一条非常重要的实践：在SpringBoot项目里，配置文件一定要叫logback-spring.xml，而不是logback.xml。

原因在于，logback-spring.xml里可以使用SpringBoot扩展的两个标签：springProfile和springProperty。前者按当前激活的profile切换配置内容，后者可以直接读取application.yml里的配置值，这两个都是原生logback.xml不支持的功能。名字只多了一个“-spring”，功能却差了一整个维度。

这是一份我平时项目里常用的模板，包含了控制台输出、按天滚动的文件输出，以及多环境开关：

<?xml version="1.0" encoding="UTF-8"?> <configuration scan="true" scanPeriod="30 seconds"> <springProfile name="dev"> <property name="LOG_PATH" value="./logs/dev"/> </springProfile> <springProfile name="prod"> <property name="LOG_PATH" value="/data/logs/app"/> </springProfile> <include resource="org/springframework/boot/logging/logback/defaults.xml"/> <include resource="org/springframework/boot/logging/logback/console-appender.xml"/> <appender name="ROLLING_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${LOG_PATH}/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOG_PATH}/app.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>200MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>${FILE_LOG_PATTERN}</pattern> <charset>UTF-8</charset> </encoder> </appender> <springProfile name="dev"> <root level="DEBUG"> <appender-ref ref="CONSOLE"/> <appender-ref ref="ROLLING_FILE"/> </root> <logger name="org.apache.kafka" level="WARN"/> </springProfile> <springProfile name="prod"> <root level="INFO"> <appender-ref ref="CONSOLE"/> <appender-ref ref="ROLLING_FILE"/> </root> </springProfile> </configuration>

两个细节值得单独说。一是这个文件里通过include引用了SpringBoot自带的defaults.xml和console-appender.xml，前者定义了CONSOLE_LOG_PATTERN和FILE_LOG_PATTERN这两个pattern模板，后者定义了名为CONSOLE的标准控制台appender。这种做法的好处是，不用自己拼日志格式，SpringBoot默认的彩色输出、时间格式、线程号这些都帮你配好了。二是springProfile标签里可以放任何logback元素，目前最常见的做法是按环境切换root的level，以及单独关闭某些吵杂第三方库的日志。

3.3 异步输出与MDC：高并发下的日志方案

日志在业务量大时也会成为瓶颈，尤其是文件IO。一次请求如果在关键路径上打了十几条日志，高并发下磁盘IO会明显拖慢接口响应。Logback提供了AsyncAppender，把日志写入操作放到异步线程中执行，业务线程只管把日志事件丢进队列就立刻返回。

我有一段实践代码是这样配置的：

<appender name="ASYNC_FILE" class="ch.qos.logback.core.AsyncAppender"> <appender-ref ref="ROLLING_FILE"/> <queueSize>1024</queueSize> <discardingThreshold>0</discardingThreshold> <includeCallerData>false</includeCallerData> </appender>

queueSize控制队列容量，超出容量时日志事件会被丢弃。discardingThreshold设为0表示队列满了之后不丢弃级别高的日志，优先丢弃INFO这类低级别日志。includeCallerData设为false可以显著提升性能，但代价是日志里无法显示代码行号，这个取舍要看需求。我的建议是：核心服务优先允许输出链路数据和错误信息，行号在高并发场景不是第一优先级。

MDC是另一个和SLF4J强绑定的实用功能。它本质是一个线程本地变量表，通过自定义的traceId把同一请求的所有日志串起来。我在网关或拦截器里通常会这样用：

import org.slf4j.MDC; import javax.servlet.Filter; import java.util.UUID; public class TraceIdFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { try { MDC.put("traceId", UUID.randomUUID().toString().replace("-", "")); chain.doFilter(request, response); } finally { MDC.remove("traceId"); } } }

然后在logback的pattern里加上%X{traceId}，日志里每行都会带上这个追踪ID：

<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] traceId:%X{traceId} %-5level %logger{36} - %msg%n</pattern>

这样在ELK或日志平台里按traceId一搜，一次请求经过的所有日志全部串成一条链路。排查线上问题时，这个字段能帮你省下大量时间。注意MDC用完要在finally里清理，否则线程池复用时会出现traceId串线的诡异问题。

3.4 {}占位符与字符串拼接的真实差距

很多人在日志代码里习惯写字符串拼接：log.debug("userId: " + userId + ", orderId: " + orderId)。这么写哪怕日志级别是INFO（DEBUG不输出），拼接操作也已经执行了，字符串对象也已经创建了。在高频调用场景下，这就是无意义的开销。

SLF4J的占位符写法是：

log.debug("userId: {}, orderId: {}", userId, orderId);

关键区别在于：当日志级别关闭时，SLF4J不会执行toString转换和字符串拼接，这些参数仅仅是对象引用，不会产生额外字符串。这就是“惰性求值”。参数多的时候，这个差距会非常明显。我还见过有人写日志时传入一个复杂的DTO对象，如果忘了重写toString，某个瞬间就会因为日志对象序列化卡住业务线程。用占位符写法再配合isDebugEnabled判断，是性能敏感场景下的标准姿势。

有一点要注意：如果入参本身是基本类型的包装类，SLF4J仍然会发生自动装箱。性能极致敏感的场景，可以考虑在方法入口处先判断isDebugEnabled()，再执行参数装配，但这属于优化到牙齿了，一般不需要。

4. 依赖冲突排查：SLF4J最常见的坑和完整链路

4.1 三种最常见的报错现场

SLF4J相关的报错有几种典型形态，我按出现频率排个序。

第一种是最经典的“多绑定”警告，完整提示是：

SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:.../logback-classic-1.2.11.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:.../log4j-slf4j-impl-2.17.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Actual binding is of type [ch.qos.logback.classic.LoggerContext]

出现这条，说明classpath里同时存在两个SLF4J实现，SLF4J会随机挑一个作为实际绑定，于是日志行为变得不可预期。某些模块的日志消失了，某些模块格式不对，都是它引发的连锁反应。

第二种是MissingResourceException或ClassNotFoundException，比如NoClassDefFoundError: org/slf4j/LoggerFactory。这通常是因为slf4j-api被某个依赖排除了，或者版本过低。SpringBoot的BOM帮我统一了版本，但如果你手动引入老版本的第三方库，它内部可能带着一个低版本的slf4j-api，覆盖了Boot管理的高版本。

第三种是NoSuchMethodError，常见提示是org.slf4j.helpers.MessageFormatter.format(...)。这基本可以断定是slf4j-api版本太低，代码里用了新版API的某个方法，但classpath里实际装的是老版本。这类问题在多模块Gradle项目里也容易踩，因为传递依赖的版本仲裁规则和Maven不同，更容易拿错版本。

4.2 用mvn dependency:tree定位冲突

遇到上述问题，第一步永远不是去猜，而是把依赖树拉出来看。Maven项目用这条命令：

mvn dependency:tree -Dincludes=org.slf4j

快速看到整个项目里所有与SLF4J相关的依赖路径。输出往往会揭示问题根源，比如某个包通过两条传递链各引入了一个日志实现：

[INFO] +- org.springframework.boot:spring-boot-starter-web:2.7.18 [INFO] \- org.springframework.boot:spring-boot-starter-logging:2.7.18 [INFO] +- ch.qos.logback:logback-classic:1.2.11 [INFO] \- org.slf4j:slf4j-api:1.7.36 [INFO] +- org.apache.kafka:kafka-clients:3.4.0 [INFO] \- org.slf4j:slf4j-api:1.7.36 [INFO] \- com.example:legacy-lib:1.0.0 [INFO] \- log4j:log4j:1.2.17

看到最后那行log4j:log4j:1.2.17，问题基本就清楚了：旧库直接依赖Log4j 1.x，而项目里没有log4j-over-slf4j做桥接，所以它的日志就落到了Log4j自己手里。

Gradle项目则用类似这条命令查依赖：

gradle dependencyInsight --dependency slf4j-api

它会告诉你每一个slf4j-api是从哪个依赖链上传进来的，以及最终解析用的是哪个版本。

4.3 正确的依赖处置姿势

定位到问题后，处置原则其实就三句话：留一个实现、桥接所有API、统一版本。

具体来说，如果项目里存在多个日志实现，只保留你要用的那个。保留Logback，就在pom中把其他实现包排除掉：

<dependency> <groupId>com.example</groupId> <artifactId>legacy-lib</artifactId> <version>1.0.0</version> <exclusions> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> </exclusions> </dependency>

如果老库迫使你保留Log4j的API，但不能让它有自己的实现，那就引入桥接包，把Log4j的调用接到SLF4J上：

<dependency> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> </dependency>

这个包会替换掉Log4j 1.x的类，使原有调用最终落到SLF4J上。

排除时有个关键禁忌：不能把slf4j-api排除掉。有些人为了消除警告，把所有slf4j相关全部排掉，结果整个项目日志直接失效，连LoggerFactory都找不到了，这种操作我见过不止一次。正确做法是用SpringBoot的BOM统一管理slf4j-api版本，业务项目不要手动指定版本。

还有一个版本陷阱：如果你的项目是SpringBoot 3.x，内置的是SLF4J 2.x，此时如果某个老库强依赖SLF4J 1.7.x，单纯排除再升级还不够，要确认所有桥接包都切换成与SLF4J 2.x配套的版本，比如log4j-slf4j2-impl，而不是log4j-slf4j-impl。

5. 生产环境日志实践：我踩过的几个坑

5.1 logback.xml与logback-spring.xml的取舍细节

这个坑我踩得印象很深。有一段时间在公司内部框架里，项目用的文件名是logback.xml，里面配了digest和pattern，所有环境都一样。后来测试环境要我单独把某个业务包的日志开到DEBUG，但生产环境要保持INFO。如果用logback.xml，我只能写死DEBUG，然后上线前再手动改回INFO，中间一旦忘记改，生产日志量会暴涨。

改用logback-spring.xml后，springProfile标签直接解决了环境差异问题：

<springProfile name="test"> <logger name="com.example.service" level="DEBUG"/> </springProfile> <springProfile name="prod"> <logger name="com.example.service" level="INFO"/> </springProfile>

自此以后，我在SpringBoot项目里一律用logback-spring.xml，默认配置的优先级后面还有SpringBoot的logging.*配置覆盖，两层机制配合起来非常灵活。

另一个细节是scan属性的使用。logback的scan=true会每60秒自动重载配置文件，这在开发环境很爽，但生产环境出现问题时，自动重载可能会掩盖“为什么我改了配置没生效”的问题。我现在的做法是开发环境开启scan，生产关闭，配置变更走发布流程。

5.2 用springProfile做多环境日志策略

多环境日志策略要管的不只是root级别，还要管具体包级别的差异化控制。比如测试环境要能看到SQL，生产环境坚决不能打SQL，这需要用springProfile切分logger。

一般的做法是:在shared配置区定义好appender和encoder，然后针对不同profile，只修改logger的level和additivity。更优雅一点的做法，利用springProperty把profile名称传进日志pattern里，这样一眼就能看出日志来自哪个环境：

<springProperty scope="context" name="activeProfile" source="spring.profiles.active"/> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [${activeProfile}] [%thread] %-5level %logger{36} - %msg%n</pattern>

但这里要注意一点：springProperty在配置加载时会读取environment，如果application.yml里没配spring.profiles.active，这个值会是空字符串，所以生产环境部署时一定要显式指定profile参数。我遇到过测试同事把日志开成DEBUG导致磁盘被撑爆的例子，根因就是没指定profile，默认走了本地配置。

5.3 root logger的边界与控制

root logger的level设置是整个日志体系的天花板，因为logger的level继承规则是：子logger未显式设置时，直接继承root的level。所以把root设成DEBUG，等于全项目所有包都输出DEBUG日志，那日志量在进入生产环境后几乎是灾难级别的。

我处理第三方库日志的常用法，是在logback-spring.xml里单独把无用的包调高level：

<logger name="org.apache.http" level="WARN"/> <logger name="org.springframework" level="WARN"/> <logger name="com.alibaba.nacos" level="WARN"/> <logger name="org.apache.kafka" level="WARN"/>

这里头的原则是：自己业务的包开DEBUG，第三方框架尽量WARN起步，要看框架日志时再单独开某个包。还有一个注意点是additivity属性，它控制当前logger的日志是否继续向上传递。某些场景你可能希望某个包的日志只输出到专门文件，不进入root的appender，那就把additivity设为false，并给它单独配置appender。

5.4 日志文件路径与滚动策略的实战经验

日志文件路径这个看似简单的问题，在真实部署环境里坑过不少人。如果你在logback配置里写的是相对路径./logs/app.log，开发环境没问题，但生产环境如果用systemd启动服务、workdir设置不对，日志就会跑到你意想不到的地方。我现在的做法是：配置文件里的路径统一用绝对路径变量，通过启动参数传进来：

java -jar app.jar --logging.file.path=/data/logs/app

或者在logback-spring.xml里定义一个可外部化的property。滚动策略上，我最常配的组合是按天滚动加单文件大小上限：

<fileNamePattern>${LOG_PATH}/app.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>200MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> <maxHistory>30</maxHistory>

单文件超过200MB就自动切分，同时保留最近30天历史，磁盘成本可控。这里有一个没写在文档里的细节：同时配置按天和按大小滚动时，一定要在fileNamePattern里加上%i，否则按大小切分时会覆盖同名文件，日志会丢失。这个丢日志的问题非常隐蔽，排查时很难想到是滚动策略的命名问题。

日志保留时间也要根据磁盘规划决定。我之前在一个磁盘只有20G的实例上部署服务，没配maxHistory，结果日志在两周内吃满了整块磁盘，线上服务直接卡死。现在无论什么环境，我都会先看一眼磁盘大小，再决定maxHistory的值。日志文件是服务运行状态的证据链，但没人希望它反过来变成事故原因。

最后说一个我自己沉淀下来的习惯：拿到一个新SpringBoot项目，第一件事就是跑一遍mvn dependency:tree -Dincludes=org.slf4j，把这个命令的输出保存下来。SLF4J相关的依赖是否干净，直接影响后面所有日志代码能不能按预期输出。很多日志问题在项目早期就埋下了，等上线后才发现再回来查，成本高得多。你可以在自己的项目里先跑一下看看，说不定已经有些暗自生效的日志实现混在里面了。