日志级别需按信息性质、使用阶段和排查价值匹配：trace用于深度链路追踪，debug面向开发测试，info记录关键业务节点，warn标识可接受的异常过程，error标记流程中断且必含堆栈与主键。

选择日志级别不是随意填个 INFO 或 DEBUG 就完事，核心是**按信息性质、使用阶段和排查价值来匹配**。级别设高了，关键线索被过滤掉；设低了，日志爆炸、性能拖慢、真正的问题反而被淹没。

按场景分清五类信息的对应级别

日常开发中真正常用的是 TRACE、DEBUG、INFO、WARN、ERROR（FATAL 很少用，通常等同 ERROR 处理）：

• TRACE：仅在极少数深度链路追踪场景下启用，比如要完整还原一次 RPC 调用中每个中间件的入参/出参顺序。一般不建议在业务代码中主动打 TRACE 日志。
• DEBUG：面向开发与测试人员，记录变量值、分支走向、SQL 绑定参数、缓存 key 计算过程等。上线后默认关闭，但需确保配置支持运行时动态开启（如通过 Actuator）。
• INFO：面向运维和初级排查者，记录系统启动完成、定时任务触发、关键业务流程节点（如“订单创建成功”“支付回调接收”）。要求语义清晰、无冗余、不泄露敏感字段。
• WARN：表示“结果可接受，但过程有异常”。例如：降级开关打开、第三方接口超时后走本地缓存、用户传了空手机号但系统用了默认值。这类日志要带上下文（谁、什么操作、为什么降级）。
• ERROR：表示“流程中断或数据不一致”，必须包含异常堆栈（用 logger.error("msg", ex)，别拼字符串）、关键入参、发生时间戳。避免只写 “服务调用失败” 这类无效信息。

按环境动态调整级别策略

同一套代码，在不同环境应启用不同粒度：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 开发环境：rootLogger 设为 DEBUG，关键包（如 com.example.service）可设 TRACE 验证逻辑流。
• 测试环境：rootLogger 设为 INFO，对 DAO 层、外部调用层单独设 DEBUG，便于验证 SQL 和 HTTP 请求是否符合预期。
• 生产环境：rootLogger 保持 INFO，仅对高频报错模块（如支付、风控）临时提升到 WARN 或 ERROR，并通过 /actuator/loggers 接口精准控制，避免全局 DEBUG 拖垮性能。

避免常见误用

这些做法看似省事，实际会降低日志有效性：

• 在 for 循环里打 INFO 日志——改用 DEBUG 并加条件判断（如每 100 条记一次），或聚合后输出汇总。
• 用 INFO 记录“用户登录成功”，却漏掉 userId、IP、设备指纹——INFO 必须带可定位的关键标识。
• catch 块里只写 log.error("DB error") 而不传异常对象——丢失堆栈，等于没记。
• 把敏感信息（密码、身份证号、银行卡号）直接打在 DEBUG 日志里——即使 DEBUG 关闭，日志文件也可能残留，务必脱敏后再记录。

验证你选得对不对

上线前快速检查三件事：

• 用 LoggerFactory.getLogger(YourClass.class).isDebugEnabled() 测试 DEBUG 是否真正生效（而不是被 rootLogger 挡住）。
• 在测试环境模拟一次 WARN 场景，确认日志里有足够上下文说明“为什么警告”“后续怎么处理”。
• 查生产 ERROR 日志，看前 10 条是否都含异常堆栈 + 至少一个业务主键（如 orderId、traceId）。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南