大家好，我是老A。
国庆假期的某天，我正懒洋洋地躺在海滩的沙滩椅上，哈着冰啤酒，海风拂面，惬意极了。
突然，手机震动个不停。点开一看，是公司告警群里接连蹦出几条「磁盘空间不足」的告警消息。虽然这不是我负责的应用，但我还是好奇地戳进去瞄了一眼。原来是日志文件膨胀得太猛，把磁盘给塞满了。没多久，负责的同事在群里发话：“这日志文件忘了挂载运维平台的自动清理脚本了。”他手动删掉一些旧日志，磁盘占用瞬间恢复正常。
这事儿让我不由得陷入了沉思。打日志，看似程序员日常中最不起眼的小事 —— 后端、前端、客户端，谁不是天天在打？但稍有不慎，轻则导致磁盘占用飙升，重则在线上故障时因为缺失关键日志而束手无策。明明是基础操作，却常常被忽略。从这个磁盘告警就能看出来，就连大厂里不少人，也没把打日志这件“小事”当回事儿。这本质上是一种认知偏差：小事不处理，往往酿成大事。
所以，今天咱们就来聊聊这个每个程序员每天都在做，但90%的人都没做对的事——打日志。把我从坑里爬出来的经验，分享给你，避免你重蹈覆辙。
第一幕：小白打日志的那些坑
说起打日志的坑，我和身边的同事们可谓是身经百战，基本上把能踩的都踩了个遍。尤其是那些刚入职的P4小白，日志打得那叫一个随性，结果往往是自食苦果。
先说第一个经典坑：日志打了个寂寞。
之前有个供应链团队的合作同事，刚校招入职，化名小张吧。我们因为项目合作频繁，关系不错，他经常来找我讨教技术问题。
有一次，他遇到一个线上偶发Bug，用户反馈操作失败。他急吼吼地跑来求助：“A哥，我在SLS里翻了半天，只有一句‘order process error！’，根本不知道是哪个用户、哪笔订单、在哪行代码出的错！这Bug没法复现，告警也没触发，日志没线索，咋办啊？”
我让他把出问题的代码发给我瞧瞧。瞄了几眼瞬间明白了：他的问题不是Bug难复现，而是就算复现了，这日志也没卵用。代码大致是这样（伪代码，展示日志打印的问题）：
@Service
public class OrderService {
public void processOrder(OrderDTO order) {
try {
// ...此处省略50行业务逻辑...
// 问题实际在这里：在某种边界条件下，order.getCustomer()可能返回null，导致NPE
String customerName = order.getCustomer().getName();
log.info("OrderService start process order..."); // 这行日志没打任何关键信息
// ...此处省略另外50行业务逻辑...
} catch (Exception e) {
// 日志打了个寂寞。。。
log.error("OrderService#order process error！");
}
}
}
大家仔细品品这段代码里的日志，相信不少新人都会心有戚戚焉。这里面藏着小白门常见的三大问题：
问题一：异常被莫名其妙地吃掉
看看catch块里，那个至关重要的Exception呢？直接被吃了！连完整的堆栈信息都不打印，也没有向上抛出，就这么被“吃干抹净”，不留痕迹。这就好比侦探赶到犯罪现场，发现一切证据都被擦得干干净净，还怎么破案？
问题二：没有任何关键信息
“OrderService#order process error！”——这是啥意思？哪个订单？哪个用户？哪个商品？日志里一个业务ID都没带。每秒钟成千上万笔订单涌入，这样的日志无异于大海捞针，纯纯浪费时间。
问题三：异常信息没有体现在日志中
error——到底是什么error？是NPE？数据库连接超时？还是RPC异常？一无所知。
最后，我叹了口气：“Bro，你的问题不是Bug无法复现，而是就算复现了，你这日志也定位不到问题。你这日志打了个寂寞啊”
第二幕：打日志的“三层境界”
是不是在小张身上看到了自己曾经的影子呢？你有思考过如何打日志这个问题吗？其实这里面还是有一些学问的。
在大厂这么多年，我总结出了打日志的“三层境界”，从P4小白到P7专家，每一级都有对应的行为特征和潜在“B面”灾难。咱们一层一层扒开，看看你处在哪一境界。
第一境：P4小白 —— 日志 = “到此一游”的涂鸦
行为特征：
- 万物皆可用System.out.println()或e.printStackTrace()。
- 日志内容随心所欲，比如log.info("111"), log.info("走到这里了")。
- 热衷于用字符串拼接（"value=" + var）来构建日志消息。
潜在的“B面”灾难：
- 性能杀手：用字符串拼接，即使日志级别被禁用，也会强制执行字符串操作（浪费资源），在高并发下严重拖慢系统。
- 信息丢失：习惯性地丢掉异常，只打印e.getMessage()而不记录完整的堆栈跟踪，丢弃了最关键的异常信息。
- 毫无价值：无法关闭，无法分级，无法被集中式日志系统（如SLS）进行有效采集和分析。线上出事时，你只能干瞪眼。
第二境：P5中级 —— 日志 = “业务流水账”
P5级别的工程师，已经懂得封装Service，但处理异常的方式，也经常存在一些问题。来看小张的另一段代码示例：
@Service
public class OrderService {
public void createOrder(OrderDTO order) {
try {
// ...业务逻辑...
String userName = null;
userName.toLowerCase(); // 这里会一个NPE
} catch (Exception e) {
// 注意：这里没有打印日志，直接向上抛出一个模糊的异常
throw new BizException("创建订单失败");
}
}
}
@RestController
public class OrderController {
@Autowired
private OrderService orderService;
@PostMapping("/orders")
public void createOrder(@RequestBody OrderDTO order) {
try {
orderService.createOrder(order);
} catch (BizException e) {
// 日志在这里打印，但没有实际异常的详细堆栈和信息
log.error("处理创建订单请求失败！", e);
}
}
}
我至今都记得，有一次为了排查一个履约单的Bug，我和另一个同事，花了整整一个通宵，在几十万行日志里，去定位一个被这样二次转手过的NPE。那种感觉，才是真正的大海中捞针。
行为特征：
- 已经学会了使用日志门面（如SLF4J）和实现（如Logback），懂得INFO, WARN, ERROR的区别。
- 日志内容开始关注业务流程，比如log.info("用户下单成功，订单号：{}", orderId)。
潜在的“B面”灾难：
- 信息孤岛，无法定位问题：日志只能证明“这个方法被执行了”，但无法串联起一个完整的用户请求链路。一旦出问题，你看到的只是散落在几十台机器上的、毫无关联的日志碎片。
- 缺少关键上下文：日志里只有orderId，但没有trace_id或其他关键的信息。大型系统中如果缺少trace_id这样的关联ID，当一个用户反馈问题时，我们根本无法从海量日志中，找到属于他的那几条。
第三境：P6/P7专家 —— 日志 = 天网
行为特征：
专家打日志，追求的不是简单“记录”，而是“可观测性”和“可诊断性”。他们会让日志成为系统的“黑匣子”。
“B面”心法：
心法一：结构化一切
- What：不再打印纯文本，而是输出JSON格式的日志。
- Why：结构化的日志，才能被SLS、ELK等系统完美解析、索引和聚合查询。这样才能解答“过去一小时，service_name为payment-processor且user_id为123的所有ERROR日志”这类问题。
- How：例如，使用SLF4J + Logback，配合JSON Encoder：
log.error("{"event":"order_creation_failed", "order_id":"{}", "user_id":"{}", "error":"{}"}", orderId, userId, e.getMessage());
心法二：上下文为王 (MDC & trace_id)
- What：MDC（Mapped Diagnostic Context）是Java中记录与线程相关的上下文的一种机制。底层使用ThreadLocal。通过 MDC，我们可以为当前线程附加一些特定的上下文信息（例如用户 ID、事务 ID），这些信息会自动与日志关联，从而帮我们更有效地分析和跟踪日志。
- Why：每条日志必须包含trace_id，用于追踪请求在多个微服务间的流转。MDC像线程的“专属背包”，在入口处放入trace_id，后续日志自动携带。
- How：在Interceptor中设置：
public class TraceInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
String traceId = UUID.randomUUID().toString();
MDC.put("trace_id", traceId);
return true;
}
}
然后日志中会自动带上trace_id：
log.error("Order failed, orderId: {}", orderId); // 会隐含trace_id
心法三：日志本身就是“炸弹”
- What：日志打印不当，可能会引发大型故障。
- Why：举个栗子：Redis超时 → 海量错误日志 → 撑爆Logstash → 丢弃日志 → 关键线索丢失。这就是日志炸弹。
- How：别直接打印复杂对象，只打印关键ID和字段。高频事件用采样，如只记录1%的INFO日志（参考EagleEye的采样策略）。
现在，针对第二境的坑，来看看P7专家的正确解法，：
@Service
public class OrderService {
public void createOrder(OrderDTO order) {
try {
// ...业务逻辑...
String userName = null;
userName.toLowerCase();
} catch (Exception e) {
// 正解：记录下最完整的错误和堆栈
log.error("创建订单核心逻辑发生异常！orderId: {}", order.getId(), e);
// 然后再向上抛出业务异常，通知上层调用失败
throw new BizException("创建订单失败", e); // 把原始异常作为cause传递
}
}
}
第三幕：宗师的视野——成熟日志系统的终极形态
在聊完打日志的三层境界后，我们不妨再往前走一步，思考一下 一个真正成熟的日志系统该是什么样子。
能力一：跨系统的“全局透视”能力
在一个分布式架构中，我们面临的第一个挑战，就是信息孤岛。成熟的日志系统，首先要解决的就是看得全的问题。通过trace_id这根线索，将一个用户请求在几十个微服务之间的完整调用，串联成一条可视化的调用链路。就像阿里巴巴的EagleEye系统那样，它能让你在上帝视角，清晰地看到一个请求从前端到数据库的每一个环节，哪里卡壳、哪里高效，一目了然。
能力二：恰到好处的数据呈现能力
看得全，不等于信息越多越好。成熟的日志系统，追求的是恰到好处。
一方面，它的每一条日志，都采用结构化的JSON格式，只包含timestamp, trace_id, span_id, error_code等最关键的字段，做到清晰、完整却不冗余。
另一方面，它有完善的过期机制。通过基于时间（保留7天）或大小（超过1GB自动轮转）的过期策略，确保日志不会成为拖垮磁盘的定时炸弹——记得我们开头的那个告警故事吧？那就是反面教材。
能力三：“先知先觉”的自动化响应能力
看得全、看得清，最终是为了效率高。一个成熟的日志系统，应该是一个半自动化的哨兵。
当它通过trace_id发现某条链路的错误率超过阈值时，它能自动触发告警，通过钉钉通知到责任人。在更高级的系统中，它甚至应该能触发自动化的修复脚本——比如隔离故障节点、回滚配置。
这，才是日志的终点：从被动的记录员，进化为主动的系统守护神。
老A时间
感谢各位兄弟的阅读。
我是老A，一个只想跟你说点B面真话的师兄。如果这篇文章让你有了一点点启发，那就是对我最大的肯定。
为了感谢大家的支持，我把这两年在一线大厂面试和带团队中，沉淀下来的所有上不了台面的私房笔记，整理成了一份《程序员B面生存手册》。
里面没有市面上千篇一律的八股文，只有一些极其管用的“潜规则”和“避坑指南”，希望能帮你少走一些弯路。
关注我的同名公众号【大厂码农老A】，在后台回复“B面”，就能免费获取。
回复“简历”获取《简历优化手册》
回复“arthas”获取史上最全的《大厂arthas实战手册》
回复“指导”获取《外包镀金手册》
回复“日志”获取《技术专家日志打印秘籍》
最后，如果觉得内容还行，也希望能点个赞、点个在看，让更多需要它的兄弟看到。
我们一起，在技术的路上结伴“陪跑”。