日志级别选择指南：DEBUG、INFO、WARN、ERROR 各自该出现的地方

刚开始写代码，日志就是 print("hello")。能出结果就行。

后来项目上了线，出事了。你翻日志翻了几百兆，全是「程序已启动」「查询已完成」，没有一条告诉你为什么慢。print 管不了级别——打了太多找不着，打了太少查不到。

日志级别不是给机器分的，是帮你在半夜三点的日志海里，一眼找到该看的那一条。

四个级别

DEBUG

开发调试用的。SQL 语句、中间件请求、框架内部——全在 DEBUG 里。

DEBUG 永远别开在生产环境。 不是废话。是真有人忘了关，线上配了 DEBUG 跑一天，一个请求几十行日志，磁盘写满才发现。不是 DEBUG 不好——是它太大了，大到线上扛不住。

INFO

打关键节点，不打心跳。 用户登录了、订单生成了、支付完成了——这些都是关键节点。系统启动、定时任务开始结束——这些是心跳，打多了只看到心跳，看不到命脉。

INFO 最难的不是打不打，是打哪儿。打多了，十几兆日志一条条翻，等于没打；打少了，出问题只有三个时间点，中间发生了什么全靠猜。

WARN

打「出事了，但没死」。 超时重试成功了、连接池满了又释放了、缓存没命中走了 DB。

WARN 和 ERROR 的边界最模糊。同一个问题，有的团队打 WARN，有的打 ERROR。标准不统一的结果：告警收到 WARN 没人起床，告警收到 ERROR 也没人起床，两个级别的区别就消失了。

定级别之前先问一件事：WARN 要不要人起床？ 要起床就是 ERROR，不要就是 WARN。

ERROR

需要人介入。 但不是 ERROR: 连接失败。这种 ERROR 跟没打一样。

ERROR 不带上下文，等于只告诉你「出事了」，不告诉你在哪。打 ERROR 要带三样东西：连的谁、什么时候连的、重试了几次。 没这些，半夜三点你看着它，不知道从哪查。

六条原则

1. 线上只开 INFO 以上。 DEBUG 开发时随便打，上了线就关。不是不让打，是生产不该打。

2. INFO 打关键节点，不打心跳。 系统启动、定时任务开始结束——打多了日志里全是这些，看不到真正出事的链。

3. WARN 和 ERROR 的边界，团队统一。 不是问「该打什么级别」，是问「WARN 要不要人起床」。每个团队标准不一样，但必须统一。否则告警收到 WARN 没人动，收到 ERROR 也没人动。

4. ERROR 必须带上下文。 连的谁、等了多久、重试了几次——少了任何一个，排查就要猜。

5. 新项目先 INFO，稳定降 WARN。 头一个月多打，你不知道哪里会出问题。稳定了再降到 WARN，日常 INFO 少到只有关键节点。

6. 别用 DEBUG 替代 INFO。 DEBUG 是给你调试看的，INFO 是给线上排查看的。开发完了 DEBUG 该关就关。

怎么选

问自己三句话：

1. 这条谁看？ 开发——DEBUG。线上排查——INFO。运维——WARN/ERROR。
2. 出事了要人动吗？ 要——ERROR。不要、但得知道——WARN。不用——INFO。
3. 这条能不能删？ 上线三个月没看过一条——删了。日志不是越多越好，是多到你自己不想翻。

日志级别的选择不是「什么该打什么」，是 谁看、什么时候看、看了能不能行动。每条日志都有一个级别，每个级别的代价是——该打的没打，查不到；不该打的打了，翻不到。