)
2026/9/12 21:26:45
FEATURED · 精选文章 
日志是开发者的“黑匣子”线上出问题时第一反应往往是去翻日志。但很多团队打印的日志要么关键时刻找不到有用信息要么日志文件爆炸式增长要么把敏感数据全盘托出。我 review 过不少项目发现下面这7个坏习惯反复出现看看你中了几个。1. 用 System.out.println 代替日志框架刚入行时我也这么干过觉得打印到控制台就够了。但 System.out 没有级别、没有时间戳、无法输出到文件、不能按包过滤线上环境根本没法用。正确做法是统一使用 SLF4J Logback/Log4j2通过private static final Logger log LoggerFactory.getLogger(Xxx.class);获取 logger让日志框架去处理输出目标、格式和级别。2. 日志级别乱用最常见的错误是把所有信息都打成 INFO导致 INFO 日志泛滥真正的错误被淹没。DEBUG 信息打 INFO异常堆栈打 ERROR 却只给一行提示。合理的做法是DEBUG 用于开发调试的细粒度信息INFO 记录关键业务流程节点比如“订单创建成功orderIdxxx”WARN 表示可恢复的异常或潜在问题ERROR 表示需要人工介入的故障。级别用对了日志才有检索价值。3. 日志缺少关键上下文只打一句“操作成功”或“查询失败”等于没打。线上排查时你需要知道哪个用户哪个订单入参是什么我习惯在日志中带上业务标识比如log.info(订单支付成功, userId{}, orderId{}, amount{}, userId, orderId, amount);。但注意不要打无意义的对象 toString既占空间又难读。4. 在循环中大量打印日志曾经见过一个批量处理任务循环里每处理一条就log.info一次一万条数据打了一万行日志磁盘瞬间写满性能也直线下降。如果确实需要记录循环内的信息应该降级为 DEBUG或者批量汇总后打印一次比如“本次处理完成成功 9999 条失败 1 条失败 IDxxx”。日志不是流水账要克制。5. 打印敏感信息这是最危险的习惯。把用户密码、身份证号、银行卡号、手机号原样打进日志一旦日志泄露就是安全事故。正确做法是脱敏手机号中间四位打星密码永远不要打身份证只留前六后四。可以封装一个脱敏工具类在打印前统一处理。另外请求体中的 token、cookie 也要过滤。6. 异常日志只打印 e.getMessage()log.error(处理失败: e.getMessage());这种写法太常见了。但 getMessage() 往往只有一句简短描述没有异常类型和堆栈根本定位不到代码哪一行出的问题。正确的做法是把异常对象作为最后一个参数传入log.error(处理订单失败, orderId{}, orderId, e);这样日志框架会自动打印完整堆栈。如果确实不需要堆栈也要打e.toString()而不是getMessage()。7. 字符串拼接且不判断日志级别log.debug(当前参数: JSON.toJSONString(request));在 DEBUG 关闭时字符串拼接和 JSON 序列化仍然会执行白白浪费 CPU。正确做法是使用占位符log.debug(当前参数: {}, request);并且对于高开销的日志先判断if (log.isDebugEnabled())。另外占位符还能避免字符串拼接带来的可读性问题。以上7个坏习惯我几乎在每个项目里都见过至少三四个。日志打印看似简单却直接影响排查效率和系统稳定性。好的日志应该像一份清晰的病历什么时候、谁、做了什么、结果如何、有没有异常。下次写log.info之前不妨多想一秒这条日志真的有用吗
日志打印的7个坏习惯，看看你中了几个
日志是开发者的“黑匣子”线上出问题时第一反应往往是去翻日志。但很多团队打印的日志要么关键时刻找不到有用信息要么日志文件爆炸式增长要么把敏感数据全盘托出。我 review 过不少项目发现下面这7个坏习惯反复出现看看你中了几个。1. 用 System.out.println 代替日志框架刚入行时我也这么干过觉得打印到控制台就够了。但 System.out 没有级别、没有时间戳、无法输出到文件、不能按包过滤线上环境根本没法用。正确做法是统一使用 SLF4J Logback/Log4j2通过private static final Logger log LoggerFactory.getLogger(Xxx.class);获取 logger让日志框架去处理输出目标、格式和级别。2. 日志级别乱用最常见的错误是把所有信息都打成 INFO导致 INFO 日志泛滥真正的错误被淹没。DEBUG 信息打 INFO异常堆栈打 ERROR 却只给一行提示。合理的做法是DEBUG 用于开发调试的细粒度信息INFO 记录关键业务流程节点比如“订单创建成功orderIdxxx”WARN 表示可恢复的异常或潜在问题ERROR 表示需要人工介入的故障。级别用对了日志才有检索价值。3. 日志缺少关键上下文只打一句“操作成功”或“查询失败”等于没打。线上排查时你需要知道哪个用户哪个订单入参是什么我习惯在日志中带上业务标识比如log.info(订单支付成功, userId{}, orderId{}, amount{}, userId, orderId, amount);。但注意不要打无意义的对象 toString既占空间又难读。4. 在循环中大量打印日志曾经见过一个批量处理任务循环里每处理一条就log.info一次一万条数据打了一万行日志磁盘瞬间写满性能也直线下降。如果确实需要记录循环内的信息应该降级为 DEBUG或者批量汇总后打印一次比如“本次处理完成成功 9999 条失败 1 条失败 IDxxx”。日志不是流水账要克制。5. 打印敏感信息这是最危险的习惯。把用户密码、身份证号、银行卡号、手机号原样打进日志一旦日志泄露就是安全事故。正确做法是脱敏手机号中间四位打星密码永远不要打身份证只留前六后四。可以封装一个脱敏工具类在打印前统一处理。另外请求体中的 token、cookie 也要过滤。6. 异常日志只打印 e.getMessage()log.error(处理失败: e.getMessage());这种写法太常见了。但 getMessage() 往往只有一句简短描述没有异常类型和堆栈根本定位不到代码哪一行出的问题。正确的做法是把异常对象作为最后一个参数传入log.error(处理订单失败, orderId{}, orderId, e);这样日志框架会自动打印完整堆栈。如果确实不需要堆栈也要打e.toString()而不是getMessage()。7. 字符串拼接且不判断日志级别log.debug(当前参数: JSON.toJSONString(request));在 DEBUG 关闭时字符串拼接和 JSON 序列化仍然会执行白白浪费 CPU。正确做法是使用占位符log.debug(当前参数: {}, request);并且对于高开销的日志先判断if (log.isDebugEnabled())。另外占位符还能避免字符串拼接带来的可读性问题。以上7个坏习惯我几乎在每个项目里都见过至少三四个。日志打印看似简单却直接影响排查效率和系统稳定性。好的日志应该像一份清晰的病历什么时候、谁、做了什么、结果如何、有没有异常。下次写log.info之前不妨多想一秒这条日志真的有用吗 
)
