在后端开发中，日志是排查问题的 “第一现场”，但很多团队的日志系统却陷入 “要么没有，要么泛滥” 的困境 —— 关键信息缺失、格式混乱、冗余日志占满磁盘，等到线上出问题时，面对 TB 级的日志文件无从下手。真正的日志管理，应该让日志成为 “可检索、可分析、可追溯” 的问题线索。
日志的核心价值与设计原则
日志的核心价值在于问题定位和系统监控，因此设计时需遵循：
- 明确性：日志内容要清晰，避免模糊表述（如 “操作失败” 不如 “订单创建失败：库存不足，商品 ID=1001”）
- 结构化：采用 JSON 格式，包含时间戳、日志级别、服务名、TraceID 等固定字段，便于检索分析
- 分级制：按严重程度分为 ERROR（错误）、WARN（警告）、INFO（信息）、DEBUG（调试），生产环境默认不输出 DEBUG
- 最小化：只记录关键信息，避免打印大对象（如完整的请求体）、敏感信息（密码、手机号）
实战技巧：让日志成为排查利器
1. 分布式追踪：用 TraceID 串联全链路
在分布式系统中，一个请求会经过多个服务，用TraceID（全局唯一）和SpanID（服务内唯一）标记调用链：
// 基于Slf4j MDC机制传递TraceID
public class TraceIdInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
String traceId = request.getHeader("X-Trace-Id");
if (traceId == null) {
traceId = UUID.randomUUID().toString();
}
MDC.put("traceId", traceId); // 存入MDC上下文
return true;
}
@Override
public void afterCompletion(...) {
MDC.clear(); // 清理上下文，避免线程复用导致的污染
}
}
// 日志格式配置（以Logback为例）
<pattern>
{"time":"%d{yyyy-MM-dd HH:mm:ss.SSS}","level":"%p","traceId":"%X{traceId}","message":"%m","service":"order-service"}%n
</pattern>
通过 TraceID，可在 ELK 等日志系统中一键搜索请求经过的所有服务日志，快速定位哪个环节出错。
2. 关键流程日志：记录 “输入 - 处理 - 输出”
核心业务逻辑（如支付、下单）需记录完整链路：
-
输入：关键参数（如订单号、金额，脱敏处理手机号 / 身份证）
-
处理：关键节点（如 “开始调用支付接口”“库存扣减完成”）
-
输出：结果（成功 / 失败原因、耗时）
反例：只记 “支付完成”，不记订单号和结果；正例：
log.info("订单支付完成，orderNo={}, amount={}, status=SUCCESS, cost={}ms",
orderNo, amount, costTime);
3. 异常日志：不要只打堆栈，要附上下文
捕获异常时，除了打印堆栈，还需补充 “当时在做什么操作，参数是什么”：
try {
paymentService.pay(orderNo, amount);
} catch (PaymentException e) {
// 错误日志包含上下文，排查效率提升10倍
log.error("订单支付失败，orderNo={}, amount={}, 原因：{}",
orderNo, amount, e.getMessage(), e);
}
避坑指南
- 避免循环日志：日志框架本身出错时可能无限打印日志，导致磁盘满（需配置日志文件大小和保留天数）
- 敏感信息脱敏：手机号显示为 138****5678，身份证显示为 310********1234
- 生产环境禁用 DEBUG：DEBUG 日志量极大，可能拖慢系统并占满存储
