日志级别选择需依据信息用途、影响范围和频率：debug用于开发调试，生产禁用；info记录业务里程碑；warn提示可预期异常；error标记需立即处理的严重故障。
选对日志级别不是凭感觉，而是看信息的用途、影响范围和出现频率。核心原则是：越关键、越需人工关注的，级别越高；越细节、越只在排查时需要的，级别越低。
DEBUG：只给开发/测试看，生产环境默认关掉
记录变量值、方法入参、中间计算结果、流程分支判断依据等——所有“我想知道它到底执行了哪条路”的细节。比如：
- logger.debug("用户ID: {}, 订单状态校验结果: {}", userId, isValid);
- logger.debug("Redis缓存key生成逻辑: prefix + {} + suffix", orderId);
注意：高并发核心路径（如支付下单入口）慎打 DEBUG，否则容易拖慢性能；上线前务必确认 logback-spring.xml 或 application.yml 中 root logger 级别不低于 INFO，避免 DEBUG 日志刷屏。
INFO：线上运维能靠它看清系统“心跳”
记录系统关键状态变化和正常业务里程碑，目标是让值班同学不看代码也能回答：“服务启动了吗？”“这笔订单走到哪步了？”“定时任务执行成功没？”。例如：
- logger.info("订单创建成功，orderId: {}, totalAmount: {}", orderId, amount);
- logger.info("配置加载完成，启用限流规则: qps={}", config.getQpsLimit());
INFO 不该包含调试细节，也不该频繁打印（比如循环体里打 INFO）。如果某条 INFO 在高峰期每秒打几百次，就要考虑降级为 DEBUG 或合并聚合输出。
WARN：问题已发生，但系统还能扛住
提示“这事不太对，但还没崩”，属于可预期的异常场景，比如参数缺失、第三方响应慢、降级策略触发、数据格式兼容性警告。重点是给出上下文，方便后续分析是否要优化逻辑：
- logger.warn("短信发送失败，将走邮件备用通道，手机号: {}, 原因: {}", phone, e.getMessage());
- logger.warn("用户头像URL为空，使用默认头像，userId: {}", userId);
别把 WARN 当 INFO 用——如果一条日志你从不查、没人告警、出了问题也帮不上忙，那它就不该是 WARN。
ERROR：必须有人马上看，可能影响业务连续性
代表不可预知的严重故障，如数据库连接池耗尽、核心接口超时熔断、NPE 导致流程中断。必须带异常对象、关键参数、唯一标识（如 traceId），确保能快速定位根因：
- logger.error("支付回调验签失败，requestId: {}, sign: {}, data: {}", requestId, sign, data, e);
- logger.error("库存扣减异常，orderId: {}, skuId: {}, quantity: {}", orderId, skuId, quantity, e);
禁止只写 message 不传 exception；禁止 catch 后吞掉异常再 throw 新异常却不打 ERROR 日志——这会让堆栈断层，找不到原始错误点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
