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

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

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

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

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

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

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

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