日志瘦身方法论，我们真的不需要吗？

说的合情合理，这2点我都赞成。 但是实践起来难，尤其企业级团队开发，除非团队有人协调。 同意楼上的，开源项目可能会好点，但商业项目有点难 看了链接的文章，方法倒不难，也在做。 问题是前人栽树后人挖坑，这种事情得要立规范，类似于《日志打印规范》，否则一个项目过了N多人的手别说日志啰混乱的一批就连变量名都猜不出是什么含义了[白眼] @只等闲 正解！ 不止要立规范，代码提交也要把关。这样才能避免日后不必要的麻烦 日志打印往往在一个时间较为紧急的项目中被忽视，而你可能会发现，我们遇到的项目，周期都不怎么松。而且实际上有没有日志，功能照样能实现，还节省了很多时间，正如单元测试的性质一样，它可能会延长项目时间 日志太多太少都不行，打印关键日志就好 但是，正所谓，慢就是快，想想，我们的维护时间往往是项目周期的两三倍以上，而维护的对象本质上是什么呢？就是我们写好的代码，若代码中缺少必要的日志打印，或者打印的日志过多过频繁，不仅不好定位问题，还有磁盘存储爆满的问题出现 慢就是快[强]，确实是这样的，后期的无法维护所耗费的时间跟精力，不如全部重构，而这导致的时间成本浪费是巨大的 @tree 我觉得是不是可以在项目后期，重构阶段把日志也重新规范起来，代码与日志规范重构当做一个独立的任务进行，从整体上让项目后期的升级迭代变得可控 这些瘦身方法并不复杂，比方法更重要的是团队意识，以及流程控制上是否能更好的落地与执行，这才是正途。 没这么复杂吧，spring不是可以控制日志的各种级别 debug、info、warn、error等，还能屏蔽指定包的log，这些还不够吗？合理的运用这些，把多余的log去掉。 把日志当做功能代码的一部分，很重要。 线上服务少打点log吧？影响性能！ 论测试的重要性