Java日志框架是上线必备基础设施，SLF4J+Logback为最优组合，解决同步阻塞、无分级、无上下文、无归档等System.out.println致命缺陷，并需规范级别使用与关键配置落地。
Java日志框架不是“锦上添花”，而是程序上线前必须搭好的基础设施——没有它，线上出问题时你连“黑盒”都打不开。
为什么不能只用 System.out.println？
看似能打印，实则埋雷：
-
System.out.println是同步 I/O，每次调用都阻塞线程，高并发下性能断崖式下跌； - 无法按级别开关（比如生产环境关
DEBUG但留ERROR），所有日志一股脑输出； - 日志混在控制台，查个错误得翻几百行、分不清是业务日志还是 Tomcat 启动日志；
- 没上下文（如用户ID、请求ID），一个报错找不到对应请求链路；
- 不支持滚动归档、压缩、异步写入，磁盘几天就被打爆。
SLF4J + Logback 是当前最稳的组合
Spring Boot 2.0+ 默认采用它，不是因为“新”，而是因为它解决了真实痛点：
-
SLF4J是门面（抽象层），代码里只写Logger接口，不绑定具体实现； -
Logback是原生实现，性能比 Log4j1.x 高 10 倍以上，且完全兼容 SLF4J； - 配置文件
logback-spring.xml支持 Spring Profile（如dev/prod不同日志级别）； - 天然支持 MDC（Mapped Diagnostic Context），一行代码就能让所有日志带上
traceId：org.slf4j.MDC.put("traceId", UUID.randomUUID().toString());
日志级别不是摆设，用错等于没用
常见误用：全项目狂打 INFO，结果线上日志量爆炸却漏掉关键线索。正确姿势是：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
-
TRACE：仅调试复杂流程（如状态机流转），默认关闭； -
DEBUG：开发/测试环境开启，记录参数、中间结果，上线前必须关； -
INFO：系统生命周期事件（启动完成、定时任务开始）、关键业务动作（订单创建成功）； -
WARN：预期外但可恢复的情况（库存扣减失败，走降级逻辑）； -
ERROR：必须人工介入的问题（数据库连接池耗尽、下游 HTTP 500）； -
FATAL：极少用，JVM 级崩溃才配得上（一般由容器或监控捕获，代码里几乎不写）。
最容易被忽略的配置细节
很多团队配完框架就以为万事大吉，结果出事才发现日志根本没落盘、没分级、没上下文：
- 没配
<appender name="FILE">？那所有日志只在控制台闪一下就消失； - 没加
<rollingPolicy>？单个日志文件涨到 20GB 还在写，运维半夜被磁盘告警叫醒； - 没设置
maxHistory="30"和totalSizeCap="3GB"？历史日志堆满磁盘，查问题时发现“昨天的日志已被删”； - 异步日志没配
includeCallerData="false"？每条日志都触发栈遍历，CPU 直接拉满； - 没在
catch块里用logger.error("下单失败", e)而是logger.error("下单失败: " + e.getMessage())？堆栈信息彻底丢失。
日志框架本身不难搭，难的是把它真正嵌进你的开发习惯和发布流程里——比如 CI 流水线自动检查 logback-spring.xml 是否含 DEBUG 级别，比如每个新接口上线前必须补全 INFO 日志点。否则，框架再强，也只是一具空壳。
