system.out.println() 不该在正式项目中承担日志职责，因其同步阻塞、无级别控制、无上下文、不可持久化，高并发下易拖慢系统；应使用 slf4j+logback 或 log4j2 等专业日志框架。
System.out.println() 不是不能用，而是不该在正式项目中承担日志职责。它本质是同步阻塞的控制台输出，没有上下文、不可配置、无法持久化，在高并发或生产环境中会拖慢系统、掩盖问题、增加运维成本。
System.out.println 的真实性能代价
每次调用都会触发同步 I/O，当前线程必须等字符写入完成才能继续执行。这不是“打印慢一点”，而是可能让业务线程卡在日志上——尤其当标准输出被重定向到文件或容器日志驱动时，I/O 延迟会被放大。实测显示：在每秒万级请求的场景下，大量 System.out.println 可额外消耗 30% 以上 CPU 时间，且容易引发线程堆积。
- 同步阻塞：无缓冲、无队列，直接抢占线程资源
- 无级别控制：INFO 和 ERROR 都一样输出，无法按需关闭调试日志
- 无上下文：不带时间戳、线程名、类名、行号，排查时分不清谁在什么时候干了什么
- 不可持久化：重启即丢，容器环境里甚至可能根本看不到输出
SLF4J + Logback 是最稳妥的替代组合
Spring Boot 默认集成 SLF4J 门面 + Logback 实现，无需额外引入依赖，开箱即用。它把日志能力标准化，又保留高性能和可扩展性。
- 声明 logger：用 private static final Logger logger = LoggerFactory.getLogger(MyClass.class);
- 参数化输出：logger.info("用户登录成功，id={}", userId) —— 避免字符串拼接，DEBUG 级别关闭时自动跳过格式化
- 异常记录：必须用 logger.error("支付失败", e)，第三个参数传 Throwable，才能保留完整堆栈
- 配置生效：通过 logback-spring.xml 控制输出格式、滚动策略、异步开关
关键配置细节决定日志是否真正可用
配了框架不等于日志就合格。很多团队配完发现“没堆栈”“太慢”“日志乱码”，往往卡在几个细节上。
- 堆栈要显式启用：%ex 或 %xEx 必须出现在 pattern 中，否则 logger.error("xxx", e) 也只打消息不打堆栈
- 异步不是万能：AsyncAppender 要配合 includeCallerData="false"（默认已是），否则每次取类/方法名会触发反射，高并发下性能反降
- 生产环境精简字段：去掉 %class、%method、%line，减少格式化开销；日志级别设为 WARN 或 ERROR，避免 INFO 泛滥
- 滚动策略建议：按天切分 + 保留 30 天，防止磁盘打满；大流量服务可加大小限制（如 100MB）
Log4j2 适合对吞吐有极致要求的场景
如果系统峰值 QPS 过万、日志量极大（如网关、风控服务），Log4j2 的 LMAX Disruptor 异步队列比 Logback 更高效，延迟更低，且支持 YAML/JSON 配置、自定义插件。
- 引入 log4j-core 和 log4j-slf4j-impl（桥接 SLF4J 接口）
- 启用异步：用 AsyncLogger 替代普通 Logger，或配置 AsyncAppender
- 错误日志单独路由：把 ERROR 日志写入专用文件或发到告警通道，避免和 INFO 混在一起
- 注意兼容性：确保没有旧版 log4j 1.x 冲突，避免 CVE 风险
