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

所有的日志打印都通过 LogUtil 类，并且日志上还得加上 code 来区分，比如 LogUtil.info("code101", "xxx")。 不能直接使用 slf4j 的 log.info("xxx")。

我完全不能理解这种操作，和他讨论了很多次，我觉得这样没有任何好处，因为 slf4j 本来就是一个门面，并且 logback 等实现提供了 Filter ，Coverter ，Appender 等扩展，完全可以通过 logback 来实现扩展，而不是侵入业务代码，并且业务也很难都改成这种方式啊。

他说是为了统一入口，便于以后扩展。但给不出具体的例子。工作了十几年了，都没产生好处，还要坚持封装。

ps：此人是我 leader 的 leader 。

请问：封装成 LogUtil 是否真的有好处，且相比 logback 扩展实现的更好，只是我没有想到，欢迎各位指点

改了就是他的 kpi：推进了 xxxlog 的自研。 你们？你们爱怎么麻烦怎么麻烦

你可以重写或者扩展 slf4j 的 log.info 的啊 ，内部调用他的 LogUtil 即可

架构师没活给你们找点活干，还行拉

也许可以规范整个公司的日志格式，好做监控和采集上报

你 leader 的 leader 说的没错，统一入口方便后面统一改造升级，比如统一的日志格式，如果日志收集处理的话这个是必要条件，直接让使用 slf4j 的结果是日志格式千千万，想统一都统一不了，问就是屎山。https://i.imgur.com/agAJ0Rd.png

如果人多了不见得大家都能遵守约定

利益分析法来分析这个问题

统一入口是最好的，就跟抛异常一个道理，你可以为异常的内容设定各种规范，但是一旦出现一个 throw new RuntimeException()，你知道的，一发不可收拾 :(

没有什么好处，他封装的扩展性还能比 logback 的好？