SLF4J的Logger不能直接new，因为它是接口，实例必须通过LoggerFactory.getLogger()获取；若无绑定实现则运行时报错且丢日志；logback.xml等配置名和位置需严格匹配，否则失效；切换日志实现需仅依赖SLF4J API，避免硬编码具体实现类；MDC变量线程不继承，需手动透传。
SLF4J的Logger为什么不能直接new？
因为Logger是接口，SLF4J只提供门面，不负责创建实例。你调用LoggerFactory.getLogger(...)时，实际返回的是底层绑定的日志实现（比如Logback的ch.qos.logback.classic.Logger）——但代码里完全感知不到。
- 错误写法：
new Logger()编译不过，接口不能实例化 - 正确入口永远只有
LoggerFactory.getLogger(Class)或LoggerFactory.getLogger(String) - 如果类路径下没有绑定实现（比如只有
slf4j-api.jar，缺logback-classic.jar），运行时会报Failed to load class "org.slf4j.impl.StaticLoggerBinder"，日志全丢弃且无提示
Logback配置文件名和位置为什么必须是logback.xml或logback.groovy？
SLF4J本身不读配置，Logback在初始化时按固定顺序查找：先找logback-test.xml（测试优先），再找logback.xml，最后是logback.groovy。名字错一个字母（比如logback.conf.xml）就彻底失效，退回到默认控制台输出，且不报错。
- 常见坑：
src/main/resources/logback-spring.xml是Spring Boot专用，原生Logback根本不认 - 如果用Maven多模块，确保
logback.xml最终被打进classpath根目录，别被子模块覆盖或遗漏 - 修改配置后要重启应用——Logback默认不热加载
logback.xml，除非显式配置scan="true"且依赖logback-core的扫描机制
切换日志实现时，为什么改个jar包就能“无缝”？
所谓无缝，是指业务代码一行不改。但前提是：只用SLF4J API（org.slf4j.*），完全避开org.apache.log4j.*、java.util.logging.*等具体实现的类。
- 如果代码里写了
new org.apache.log4j.Logger()或import java.util.logging.Logger，换SLF4J绑定毫无意义 - 依赖冲突是最大风险：比如项目间接引入了
slf4j-log4j12.jar和logback-classic.jar，SLF4J会随机选一个绑定，同时报Class path contains multiple SLF4J bindings警告——日志可能部分丢失 - 验证是否真解耦：删掉所有
logback-*.jar，只留slf4j-simple.jar，看日志是否照常输出（格式变简陋但不崩）
logback.xml里%X{traceId}这种MDC变量为什么有时为空？
MDC（Mapped Diagnostic Context）是线程局部的，不是全局共享。它只对当前线程有效，子线程、线程池任务、异步回调里默认不继承。
立即学习“Java免费学习笔记（深入）”；
- Web场景下，通常在Filter里
MDC.put("traceId", ...)，但Spring MVC的异步方法（@Async）、CompletableFuture、线程池提交的任务都会丢失 - Logback配置中
%X{traceId}没值，不代表没设，很可能是设在别的线程里了 - 修复关键：用
org.slf4j.MDC.getCopyOfContextMap()捕获父线程MDC，在子线程启动前用MDC.setContextMap(...)还原；或者用Logback 1.3+的includeCallerData="true"配合自定义Converter做透传
真正麻烦的从来不是配对儿，是MDC在复杂线程模型里的生命周期管理——它不会自动跨线程，也不会自动清理，漏一次就埋个排查黑洞。
