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

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

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

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

ps：此人是我 leader 的 leader 。

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

绝对有好处啊。结合调用链，有利于跨平台日志收集、分析、追踪，不过前提是，你公司的得有这些基础设施。

统一成一个不用动脑的样子不好吗，不然 private static final java.util.Logger LOGGER public final static slf.Logger logger private logback.Logger loger private log4j.logger log 更爽吗？虽然最后都是 logback

@sxms77777 你说的这些现在的日志框架不能实现吗？ slf4j 换日志框架那么方便。而且日志框架就打印字符串，有啥复杂的 api 我是没太理解

打工混日子你和 leader 较什么真呢，他最起码知道 logutil 不会出大问题，技术选型肯定选自己熟悉的。

感觉收益不大，完全不需要这样做，大面积推广一个东西，必须有充分的理由和解决实际问题为目的。

@sxms77777 再补充下，如何需要一些对日志框架做拓展，也无需改到业务

1. 以后换了日志框架，业务层不会有任何修改 2. 单元测试方便 mock 3. 模糊业务对细节的了解，防止他们使用一些不科学的 api

没啥毛病 理论上一些高阶功能无法走扩展，尤其是公司内部的一些基础设施集成 对于用户来说最简单的方法集成公司现有平台是最好的改造方向 想法是好的，但得把功能点先列出来 这种东西作为基础设施一环，想不清楚就是一坨，想清楚了整个公司数据一致性都会提高 你老板如果写不出来具体 feature 可以给方向 但感觉他也不太懂

@k9982874 1. slf4j 门面和 logback 等实现提供的扩展性都可以做到，楼主也说了，这些不是问题。 2. 每个语言有自己的最佳实践，别的语言或许封装一个 LogUtil 更为合适，但 Java 没必要。即使封装了 LogUtil ，也应该允许让其作为 slf4j 的实现，而不是不允许使用 slf4j 直接打印日志。此外，不同平台的日志不一定是统一管理。 3. 不存在模板复制的问题，安全、日志相关的自定义 sdk 使用 snapshot ，每次从 mvn repo 拉取最新版本。