所有的日志打印都通过 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 的结果是日志格式千千万，想统一都统一不了，问就是屎山。

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

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

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

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

方便监控吧，根据上下文加一些标准的字段和格式，就能统一收集处理了。

正常吧，不然日志采集，监控报警不好；日志格式后期还是要规范的；

正解

格式是规范了的，已经在 sdk 里提供了统一的 logback.xml ，现在问题是，打印日志需要封装一个 LogUtil 吗

比如 logback ，可以通过 converter 机制来增加字段，只需要实现一个 converter 类，然后修改 logback.xml 即可

spring 有可以配置日志格式的地方，slf4j 的 logger 可以标识是哪个类打的日志，蛮有用处的，LogUtil 感受不到太大的好处

日志加密、日志脱敏？

那我写出来怎么推广出去啊，他又不推广，总是 push 我们推广，我没有充足的理由让各个业务团队这么改

推广是他的事，怎么成你的任务了？

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

日志封装是很常见的操作啊，后期可以根据 code101 来做源代码级别的筛选/过滤/屏蔽。

如果维护的人经常变动，统一代码格式挺重要的。当然不离职，怎么方便怎么来。

他可能属于那种不接受新鲜事物的人，内心鄙夷这种框架，你自己写他学习成本也会变低

kpi 而已

没什么好处，自定义 LogUtil 能做到的功能，在 Filter, Appender 层面完全可以做到。

LogUtil.info("code101", "xxx") 跟 log.info("code101", "xxx") 并无区别。

没好处，楼上说到的日志格式、脱敏加密、监控采集等都可以通过项目中引用 sdk 来实现，不需要改代码形式。

再者说，封装的 LogUtil 的扩展性谁来保证，动来动去的更麻烦。

我们当前的日志是排查问题用的，整个 code 对我排查问题没什么帮助，现在都有分词，还有 logger name 之类的来筛选。
日志格式是统一的，比如 level ，time ，threadname ，自定义 mdc 这些

＃13 为了以后的扩展变更还是需要的，万一出了一个比 slf4j 更好用的呢？或者需要对日志统一做一些额外处理呢？无规矩不成方圆，对于稍微大点的项目，应该全部禁止直接引用第三方包，而是需要自己包装下才可以，都是千万屎山得来的教训，等你坐到他那个位置，你可能要求比他更夸张

你别说 我还真见过用 LogUtil.info 这种的

他是领导他说了算，建议类名叫 SBLogUtil ，要是领导问 SB 前缀是什么含义，你就说 Spring Boot 的缩写

太年轻了，没有被屎山教育过

屎山见多了，只是不知道 LogUtil 怎么防范屎山

纯技术上讲，他对 facade 理解不够或者能力所限……但是考虑到国情和企业环境，也许你有机会能理解他的做法。

他是架构师，你是程序员，你如果一下就理解了，他架构师的水分也太大了。

LogUtil.info("code101", "xxx")

这样可以快速通过 code101 来排查啊

没任何好处，相当于进行了一次没有太大意义的封装，入侵性还大。
可能他不知道能直接扩展，基于自己的认知和经验就只是再包一层封装...

小的个人开发者的类库，我会封装 API ，防止跑路
slf4j 也要这么搞，太闲了吧

纯纯浪费时间。

相信你们肯定用了很多开源库吧，开源库也要打日志吧。slf4j 作为门面，很多开源库也是用它打日志。
下面问题来了，这些日志怎么办？让你们的架构师给这些开源库推 PR 吧，改用你们的；
或者，想到了人家不会接受，那就把用到的开源库都 fork 一份自己维护吧，这样接下来十年的 kpi 都有了……

这个架构师真是吃饱撑的。他厉害，可以替换 logback 啊，可以指定日志规范啊，制定规范，监督规范的执行，也是 kpi 啊。

沟通问题不要尝试通过技术解决 [狗头]

需要看你们这个 logUtil 是不是为了特殊日志做准备的吧，比如你们日志比较多，存储有特异性（管道到某个公司内部的采集系统，二进制压缩存储等），高吞吐量（需要单独设计缓存区），复杂的上下文打印这些功能，只能如果架构师在推广一个 sdk 的时候无法说出理由，大概率就是一个 kpi 产物了

可能是为了方便扩展？比如后续收集日志进行统计分析之类，自动收集 crash 等等

评价为不如
www.elastic.co/guide/en/ecs-logging/java/current/index.html
和
spring.io/blog/2024/08/23/structured-logging-in-spring-boot-3-4

线上出问题的时候动态修改 log level?

脱裤子放屁

好处是不用每个类定义 log 对象？没感觉有其他啥好处，新项目改就改了吧，旧项目让他自己改

这个就是统一日志格式吧。。做日志搜集的时候方便，不然如果每个人写一个格式怎么解析

＃26 如果是其他库或许可以这么说，但是 slf4j 出了 18 年了，在 mvnrepository 它是
＃2 in MvnRepository
＃1 in Logging Frameworks

Quartz 、Camel 、Akka 等有多少库使用了 slf4j

至于各种日志扩展，通过 Coverter 、Appender 等都可以实现，提供 sdk 引入即可，不需要侵入代码

非要说好处就是可以强制调用者提供一个代码。非要说必要性那肯定是没有。可能这人岁数比较大，旧项目里代理的习惯。

不定规范，相当于在一坨💩山旁再拉一坨

日志收集不是靠入侵业务代码实现的吧。我个人觉得日志用 util 类封装，然后放入业务代码里是很垃圾的做法。一方面要大批量改 log.info 代码，另外一方面后续接受的人并不会明白这个做法，增大代码 review 复杂度以及后续接收复杂度。po 主既然讨论了，能否把架构师的理由说出来听听。单纯统一入口，便于以后扩展不是理由，slf4j 已经足够抽象化。提出一个方案，必然是解决某个痛点，而不是过度设计

从工作的角度，人家说啥就整啥就完事了
从经验的角度，我们也封了，但是总体来说 API 没啥变化，logger 看上去还是那个 logger 但是差了一些逻辑，直接出新 API 不是什么好文明
从自己的角度，应付过去就完事了，别耽误下班别耽误发工资就行

个人感觉目前看是为了规范，保不齐后面就变成新的屎山

封装 LogUtil 很难理解吗？
封装 log 是统一格式，数据脱敏，数据清洗，大数据分析的第一步啊。
你只看你自己的业务，你们公司还有别的业务，其它语言写的平台吧，没有 slf4j 怎么办？
即使有 slf4j 开新项目每次都复制模板？模板分叉了怎么办？哪个模板是最新的？
天天制造屎山，还天天骂屎山

你不改怎么体现他的价值，他不给你提需求怎么体现你的价值？

存粹是菜

没什么好处，并且代码很难看，统一入口不是这么个统一法

封装很常见，但是自己封装一个 Util 不常见，一般对日志有要求的，那么就基于 sl4j 做一个专门的 factory ，让业务无痛切换，底层实现格式化

+1

你说的这些其他日志框架都实现了，而且性能更好，完全没必要自己造轮子。数据脱敏，数据清洗，大数据分析也不靠入侵业务代码实现，Logstash 、Fluentd 。多语言、多平台靠使用统一的日志收集平台 ELK 。LogUtil 这种入侵业务代码的非业务代码才会造成屎山，让人摸不着头脑。

1. slf4j 门面和 logback 等实现提供的扩展性都可以做到，楼主也说了，这些不是问题。

2. 每个语言有自己的最佳实践，别的语言或许封装一个 LogUtil 更为合适，但 Java 没必要。即使封装了 LogUtil ，也应该允许让其作为 slf4j 的实现，而不是不允许使用 slf4j 直接打印日志。此外，不同平台的日志不一定是统一管理。

3. 不存在模板复制的问题，安全、日志相关的自定义 sdk 使用 snapshot ，每次从 mvn repo 拉取最新版本。

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

你老板如果写不出来具体 feature 可以给方向
但感觉他也不太懂

1. 以后换了日志框架，业务层不会有任何修改

2. 单元测试方便 mock

3. 模糊业务对细节的了解，防止他们使用一些不科学的 api

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

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

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

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

   统一成一个不用动脑的样子不好吗，不然

private static final java.util.Logger LOGGER
public final static slf.Logger logger
private logback.Logger loger
private log4j.logger log

更爽吗？虽然最后都是 logback

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

不过说实话，我还挺喜欢 LogUtil 这种静态工具类打印日志的用法，不需要在类里面专门声明一个变量，免得老是没用上然后报 unused warning

多干点活，不然天天没事，把你们裁了。这叫供给端改革，不用管消费端需不需要。

不但毫无意义，反而会增加定位难度，日志自动携带的代码，类等信息已经方便定位了，加"codexxx"这种需要人为手动填写，全靠人为约束的东西，只会增加日志定位的复杂度。

那你就封装 slf4j ，把 code 码注入进去要求必传参数就好了呗，反正 slf4j 就是抽象出来的，你上面多抽象一层。

＃65 这个帖子挂在"程序员"节点下，而不是"Java"节点下，感觉很多回复是对 Java 生态不太了解。看了你的几条回复，我和你的观点是比较一致的😁

挺好的，但是如果你是业务团队，要提要求：
1 兼容目前 slf4g 所有 api ，业务侧无改动成本
2 如果因为 logUtil 导致的 bug 和故障，要架构师负责

哈哈习惯就好。jsonutil ，datautil ，redisutil ，cacheutil ，stringutil ，lockutil 还少吗

你用其他方法打印日志,不就是找喷。

扩展也可以理解。
后面可能考虑,丢 es 其他产品的日志呢,或者更加自定义的操作。

楼主可以问问 AI ，我把问题直接丢给了 gemini 2.0, claude 3.5 sonnet, gpt-4o ，似乎都更推荐 SLF4J + Logback

很多人可能不了解 java 生态下的 SLF4J ，什么动态日志级别，源码级别的日志过滤，这些都是自带的。相比其他语言来说真的是很完善了。

完全不能理解这种行为，库都提供好了非得自己再包一层然后弄成 static ，然后 util 对外暴露的 api 还更少了想用的时候又自己加一个方法。

职业生涯最重要的一课是，你需要认识到，你工作的目的不在于使得公司的客户满意，而在于使得那些控制你的加薪、奖金和晋升的人满意。

你想多了，出了事架构师不可能负责的，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 自己拿小本本记着，那是绝杀。
换别人排查日志定位不到问题，自己一看就能定位，建立壁垒，避免了被取代裁员。
（透过现象看本质，到了这个级别，追求的不是什么扩展性和实用性了，而是利益了）