Java日志环境配置详解

SLF4J + Logback 是当前最稳妥的Java日志组合，推荐使用 slf4j-api 2.0.13 和 logback-classic 1.4.14，配置文件须置于 classpath 根目录，通过系统属性动态控制日志级别，并注意 MDC 在异步场景下的手动传递。

Java日志框架选型：SLF4J + Logback 是当前最稳妥的组合

Java 本身有 java.util.logging（JUL），但实际项目中几乎没人直接用它——功能弱、配置僵硬、桥接麻烦。主流选择是 SLF4J 作为门面（facade），底层绑定 Logback（原生支持 SLF4J，性能好、配置灵活）。避免用 log4j2 除非有明确需求（如异步日志吞吐压测），否则会多一层 slf4j-log4j2 桥接，还容易因版本不匹配触发 NoClassDefFoundError: org.apache.logging.log4j.spi.LoggerContextFactory 这类错误。

• 确认 Maven 依赖只保留一组：移除所有 log4j、commons-logging、java.util.logging 直接引用
• 只引入：

  <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>2.0.13</version>
  </dependency>
  <dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.4.14</version>
  </dependency>

• logback-classic 已包含 slf4j-api 的实现，无需额外加 slf4j-simple 或 slf4j-jdk14

logback.xml 配置必须放在 classpath 根目录

Logback 启动时会按固定顺序查找配置文件：logback-test.xml → logback.xml → logback.groovy。开发阶段优先用 logback-test.xml（放在 src/test/resources），生产用 logback.xml（放在 src/main/resources）。放错位置（比如写成 config/logback.xml）会导致 Logback 回退到默认控制台输出，且控制台会打印警告：WARN in ch.qos.logback.classic.LoggerContext[default] - No appenders present...

• 检查编译后 target/classes/（Maven）或 out/production/（IntelliJ）下是否存在 logback.xml
• 配置中路径使用相对 classpath 路径，例如：<file>logs/app.log</file> 表示在 JVM 启动目录下创建 logs/app.log，不是 classpath 里找
• 避免在 <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> 中漏写 <encoder>，否则日志内容为空白行

区分开发与生产环境的日志级别和输出目标

开发时需要看到 DEBUG 级别日志快速定位问题；生产必须关掉 DEBUG，防止磁盘打满或敏感信息泄露。不能靠改代码里的 logger.debug("...")，而应通过配置动态控制。

• 在 logback.xml 中用 <springProfile>（Spring Boot）或 <if>（需引入 logback-core 的 Janino 支持）做环境分支
• 更轻量的做法：用系统属性区分，例如启动时加 -Dlog.level=DEBUG，然后配置：

  <root level="${log.level:-INFO}">
    <appender-ref ref="CONSOLE"/>
    <appender-ref ref="FILE"/>
  </root>

• 生产环境禁用 CONSOLE appender，只留滚动文件；开发环境可加 AsyncAppender 包裹 FILE，减少 I/O 阻塞

避免日志中出现线程安全或格式化异常

SLF4J 的占位符语法 logger.info("User {} logged in at {}", userId, LocalDateTime.now()) 是线程安全的，且只有当日志级别允许输出时才真正执行参数计算。但若手写字符串拼接：logger.info("User " + userId + " logged in at " + LocalDateTime.now())，每次都会构造对象、触发 toString()，浪费 CPU 和 GC 压力。

• 禁止在日志参数中调用可能抛异常的方法，例如：logger.error("Failed to parse JSON", jsonNode.toString()) —— 若 jsonNode 为 null，直接 NPE，日志都打不出来
• 敏感字段（密码、token、身份证号）必须脱敏后再传入日志，不能依赖日志框架过滤（Logback 的 Filter 是事后扫描，已进内存）
• 异步日志（AsyncAppender）下，MDC（Mapped Diagnostic Context）不会自动继承，需显式调用 MDC.copyInto 或改用 LoggingEventAsyncDisruptor 等替代方案

Logback 的配置自由度高，但也意味着出错时排查路径长：从类路径、XML 语法、appender 初始化顺序，到 MDC 传递、异步缓冲区大小，每一步都可能静默失败。最常被忽略的是 RollingFileAppender 的 <timeBasedFileNamingAndTriggeringPolicy> 里没配 maxHistory，导致日志文件无限累积。