公司的架构师要求把日志封装成 LogUtil 类，提供 sdk 给各团队使用，并且不允许使用 slf4j 直接打印日志，请问各位这么做有哪些好处（我还没想到任何好处）？

@meeop 你想多了，出了事架构师不可能负责的，logUtil 又不是架构师开发的，是架构师让你开发的，“不是我领导无方，而是你能力不行”。

假设确定了要写，那么大概有两种方案。

一、第一种方案，就是 LogUtil 内部调用其他日志框架来打日志。

1.1 、这就引入一个致命问题，就是类信息怎么传过来？你看哦，日志框架其实是需要在类里生成一个`private static final Logger log = LoggerFactory.getLogger(所在类.class);`所以打印的时候，才能打印出是哪个类的问题，但此时你是 LogUtil 来打印，那么所有的日志都会变成 LogUtil 的日志。怎么解决这个问题？

1.2 、第二个问题，如果我没封装，那日志框架出了问题（比如上次的 log4j2 漏洞），就是日志框架的问题。但如果我封装了 LogUtil ，那此时就是写 LogUtil 的人的问题。因为是你选择了内部要调用其它日志框架。

二、第二种方案，就是不调用其他日志框架。哦我的上帝啊，那样就会引入更多问题。

你得写自己的 Logger 、LoggerFactory 、 设计自己的 logback.xml 等等，最终还就是自己做了一个日志框架。

还有最终的致命问题，你程序里写的日志可以改成调用 LogUtil 的，那调用的第三方 jar 包里写的日志你怎么控制？



把这些问题抛给你 leader 的 leader ，让他解决

这波架构师在大气层啊，这样大家都有活干，有绩效，对项目影响又不大。
防御性编程，如果再加上不写文档，Code 自己拿小本本记着，那是绝杀。
换别人排查日志定位不到问题，自己一看就能定位，建立壁垒，避免了被取代裁员。
（透过现象看本质，到了这个级别，追求的不是什么扩展性和实用性了，而是利益了）

我觉得还是有好处的，只是是什么阶段什么时候做合不合适的问题。
也不要觉得做这个事情的目的想的那么功利，本来加薪就是要做事情。（前提是别搞幺蛾子比如大家明明忙不过来还要搞这种事情）
是真的有些人是想在代码上面有写追求的，哪怕公司没有加薪计划。
所以遇到这种事情，你不明白的话就问问他这么做的目的，让他给你解释解释，相当于请教一下（也可以学学领导的思维方式，也有好处），如果他跟你解释了你还是不能理解，那就问问他应该怎么实现，然后按照他的想法去实现就行，退一万步讲，写代码的写什么代码不是写？
我主要还是说这件事情本身，如果做这个事情的过程比较恶心，那我觉得是另外一个范畴的问题了。

站在顶层看，封装是没任何问题的，但也不一定是要封装的，封装后的优点如下：

- 统一日志框架版本。举例，log4j 漏洞升级版本，那就不用每个项目都修改一遍了

- 统一定义日志格式，方便搜集/格式化/分析/告警/数据看板等等

- 并不是所有人都知道 slf4j 是门面，有的应用日志框架实现是 log4j2 、有的是 logback ，当然统一最好啦

- 增强 code 我理解为，提升可维护性

现在你们有做日志采集吗，比如采集槽 ELK ，如何有的话，统一日志是有必要的

新项目可以理解，改现有的没有必要

个人经验, 工作中看到 “封装” 这个 2 个字就没好事.

你的 slf4j 方案有办法让人不带上 code101 就编译不了么?

统一是好的，遇到过匿名化诉求，这个时候统一好处就来了

新需求，把所有 info 日志加埋点。or 这个日志性能太差了，灰度换其他的。评估下工作量

讲不清楚真正的具有说服力的优点的基本上说明没啥水平。统一日志（用来做分析）和你用的 log 封装根本没有直接关系，那主要是数据质量问题。

搞清楚自己的定位,就是个干活的

我司不规定日志实现，只规定日志格式，还必须是结构化的日志，不允许平铺直叙打日志

LogUtil.info ，我倒没啥意见，我们公司几千个研发，也是这么干的。当然我们是 Go ，没有 slf4j 这类事实上标准规范。但其实不关心 LogUtil 底层是咋实现的，只是打个日志，你可以在你自己的框架里面包一下（用起来还是 log.info ）
好处前面很多人也提过了，日志脱敏、存储的统一性。虽然有点搓，但也无伤大雅。
不过肯定有性能的要求，开发 LogUtil 的团队需要给出性能报告，以及承担相关责任（比如日志库 panic 了，平台上查不到日志了）

我倒是反对加上 code101 ，这种纯沙币的行为，完全不可控，很容易就重复了，还不如直接记录文件名+行

已经有 TCP 了，为什么大家不用 TCP 实现一切，还要在他上面发明个 HTTP ？明明什么问题都没解决

不是很好……统一的话直接在框架里下毒就行。我们就是这么干的。提供统一的 logback.xml ，然后各个实现类里自己引入 org.slf4j.Logger

反倒是有副作用？不知道怎么封装的，一般现在日志前面会有一个缩略的日志打印的类的类名。不知道他封装后是不是丢了。。。

如果不是通过框架全局做单纯用 Util 封装的话，封装后还会有几个问题：
1. IDE 的括号和变量个数是否匹配的检查不会生效了。
2. 其他第三方库并不会按照你们的规范来……

统一入口没毛病，日志 code 最好有个可扩展的枚举类之类的东西去约束。

你是不知道没统一日志工具类的情况，对本来各自为战的各个开发负责的各个不同风格的项目，统一做日志整改有多困难。

统一的好处就是好管理，日志工具也可以集成类似响应时间或者特定事件的监控，哪天公司要求对某些事件做监控报警了，限期做改造，然后你发现项目张三两个李四三个，却没用到统一的日志工具，整改起来你就头疼去吧。


有些日志侵入业务是因为一开始对日志没要求，或者说一开始业务没考虑日志和监控的需求，但是不代表这需求不合理。

人家重点是那个 code 🤣 你解决不了那个 code 就无法说服他