公司的架构师要求把日志封装成 LogUtil 类，提供 sdk 给各团队使用，并且不允许使用 slf4j 直接打印日志，请问各位这么做有哪些好处（我还没想到任何好处）？
WillingXyz · 15 小时 50 分钟前 · 11456 次点击所有的日志打印都通过 LogUtil 类，并且日志上还得加上 code 来区分，比如 LogUtil.info("code101", "xxx")。 不能直接使用 slf4j 的 log.info("xxx")。
我完全不能理解这种操作，和他讨论了很多次，我觉得这样没有任何好处，因为 slf4j 本来就是一个门面，并且 logback 等实现提供了 Filter ，Coverter ，Appender 等扩展，完全可以通过 logback 来实现扩展，而不是侵入业务代码，并且业务也很难都改成这种方式啊。
他说是为了统一入口，便于以后扩展。但给不出具体的例子。工作了十几年了，都没产生好处，还要坚持封装。
ps：此人是我 leader 的 leader 。
请问：封装成 LogUtil 是否真的有好处，且相比 logback 扩展实现的更好，只是我没有想到，欢迎各位指点
第 1 条附言 · 10 小时 52 分钟前
补充下，统一日志框架、统一日志格式已经做了，通过提供 sdk 实现的。
另外，至于说限流、自定义序列化、增加上下文信息字段，这些可以通过 Filter 、Converter 等扩展无侵入的方式实现，所以我才觉得 LogUtil 没必要。
而打印日志的时候加个 code ，是 slf4j 做不到的，但没觉得加这个有什么好处，而且实施难度太大，有点理想化。
我业务日志是排查问题用的，不是用于数据分析的，我根据 logger name ，行号，模糊匹配都能定位，没必要用 code ，日志区分度有这么低吗
另外，至于说限流、自定义序列化、增加上下文信息字段，这些可以通过 Filter 、Converter 等扩展无侵入的方式实现，所以我才觉得 LogUtil 没必要。
而打印日志的时候加个 code ，是 slf4j 做不到的，但没觉得加这个有什么好处，而且实施难度太大，有点理想化。
我业务日志是排查问题用的，不是用于数据分析的，我根据 logger name ，行号，模糊匹配都能定位，没必要用 code ，日志区分度有这么低吗
第 2 条附言 · 6 小时 12 分钟前
各位说的对，既然架构师说要做，那就按他说的做吧，我也只能执行啊。毕竟他是领导，和领导对着干没好处，学到了。
145 条回复
 |
1
RightHand 15 小时 48 分钟前 via Android  25
改了就是他的 kpi：推进了 xxxlog 的自研。
你们？你们爱怎么麻烦怎么麻烦 |
 |
3
iikebug 15 小时 46 分钟前 1
架构师没活给你们找点活干，还行拉
|
 |
4
mohyz 15 小时 45 分钟前
也许可以规范整个公司的日志格式，好做监控和采集上报
|
 |
5
unknown404 15 小时 45 分钟前 12
你 leader 的 leader 说的没错，统一入口方便后面统一改造升级，比如统一的日志格式，如果日志收集处理的话这个是必要条件，直接让使用 slf4j 的结果是日志格式千千万，想统一都统一不了，问就是屎山。
 |
 |
6
theniupa 15 小时 43 分钟前
如果人多了不见得大家都能遵守约定
|
 |
7
skyrim61 15 小时 43 分钟前
利益分析法来分析这个问题
|
 |
8
nealHuang 15 小时 42 分钟前
统一入口是最好的，就跟抛异常一个道理，你可以为异常的内容设定各种规范，但是一旦出现一个 throw new RuntimeException()，你知道的，一发不可收拾 :(
|
 |
9
Wh1te 15 小时 42 分钟前
没有什么好处，他封装的扩展性还能比 logback 的好？
|
 |
10
daya0576 15 小时 42 分钟前
方便监控吧，根据上下文加一些标准的字段和格式，就能统一收集处理了。
|
 |
11
azwcl 15 小时 41 分钟前
正常吧，不然日志采集，监控报警不好；日志格式后期还是要规范的；
|
 |
13
WillingXyz OP |
|
14
WillingXyz OP @daya0576 比如 logback ，可以通过 converter 机制来增加字段，只需要实现一个 converter 类，然后修改 logback.xml 即可
|
 |
15
devilweime 15 小时 34 分钟前
spring 有可以配置日志格式的地方，slf4j 的 logger 可以标识是哪个类打的日志，蛮有用处的，LogUtil 感受不到太大的好处
|
 |
16
2han9wen71an 15 小时 34 分钟前
日志加密、日志脱敏？
|
|
17
WillingXyz OP |
|
18
RightHand 15 小时 31 分钟前 via Android
推广是他的事，怎么成你的任务了？
|
 |
19
huguohuan 15 小时 30 分钟前
也许可以规范整个公司的日志格式，好做监控和采集上报
|
 |
20
tool2dx 15 小时 29 分钟前
日志封装是很常见的操作啊，后期可以根据 code101 来做源代码级别的筛选/过滤/屏蔽。
如果维护的人经常变动，统一代码格式挺重要的。当然不离职，怎么方便怎么来。 |
 |
21
Fca 15 小时 26 分钟前
他可能属于那种不接受新鲜事物的人，内心鄙夷这种框架，你自己写他学习成本也会变低
|
 |
22
fengpan567 15 小时 24 分钟前
kpi 而已
|
 |
23
sagaxu 15 小时 24 分钟前
没什么好处，自定义 LogUtil 能做到的功能，在 Filter, Appender 层面完全可以做到。
LogUtil.info("code101", "xxx") 跟 log.info("code101", "xxx") 并无区别。 |
 |
24
lucasdev 15 小时 22 分钟前
没好处，楼上说到的日志格式、脱敏加密、监控采集等都可以通过项目中引用 sdk 来实现，不需要改代码形式。
再者说，封装的 LogUtil 的扩展性谁来保证，动来动去的更麻烦。 |
|
25
WillingXyz OP @tool2dx 我们当前的日志是排查问题用的，整个 code 对我排查问题没什么帮助，现在都有分词，还有 logger name 之类的来筛选。
日志格式是统一的，比如 level ，time ，threadname ，自定义 mdc 这些 |
|
26
unknown404 15 小时 19 分钟前 2
@WillingXyz #13 为了以后的扩展变更还是需要的，万一出了一个比 slf4j 更好用的呢？或者需要对日志统一做一些额外处理呢？无规矩不成方圆，对于稍微大点的项目，应该全部禁止直接引用第三方包，而是需要自己包装下才可以，都是千万屎山得来的教训，等你坐到他那个位置，你可能要求比他更夸张
|
 |
27
luobingit 15 小时 18 分钟前
你别说 我还真见过用 LogUtil.info 这种的
|
 |
28
lululau 15 小时 17 分钟前 43
他是领导他说了算，建议类名叫 SBLogUtil ，要是领导问 SB 前缀是什么含义，你就说 Spring Boot 的缩写
|
 |
29
neocanable 15 小时 13 分钟前
太年轻了，没有被屎山教育过
|
|
30
WillingXyz OP @neocanable 屎山见多了，只是不知道 LogUtil 怎么防范屎山
|
 |
31
boywang004 15 小时 8 分钟前
纯技术上讲，他对 facade 理解不够或者能力所限……但是考虑到国情和企业环境，也许你有机会能理解他的做法。
|
 |
32
HtPM 15 小时 8 分钟前
他是架构师，你是程序员，你如果一下就理解了，他架构师的水分也太大了。
|
 |
33
CodeCodeStudy 15 小时 6 分钟前
|
 |
34
hafuhafu 15 小时 5 分钟前
没任何好处，相当于进行了一次没有太大意义的封装，入侵性还大。
可能他不知道能直接扩展，基于自己的认知和经验就只是再包一层封装... |
 |
35
fredweili 15 小时 4 分钟前
小的个人开发者的类库，我会封装 API ，防止跑路
slf4j 也要这么搞，太闲了吧 |
 |
36
piecezzz 15 小时 1 分钟前
纯纯浪费时间。
|
 |
37
flmn 15 小时 0 分钟前 1
相信你们肯定用了很多开源库吧，开源库也要打日志吧。slf4j 作为门面，很多开源库也是用它打日志。
下面问题来了，这些日志怎么办？让你们的架构师给这些开源库推 PR 吧，改用你们的； 或者，想到了人家不会接受，那就把用到的开源库都 fork 一份自己维护吧，这样接下来十年的 kpi 都有了…… 这个架构师真是吃饱撑的。他厉害，可以替换 logback 啊，可以指定日志规范啊，制定规范，监督规范的执行，也是 kpi 啊。 |
 |
38
ichou 14 小时 58 分钟前
沟通问题不要尝试通过技术解决 [狗头]
|
 |
39
chawuchiren 14 小时 55 分钟前
需要看你们这个 logUtil 是不是为了特殊日志做准备的吧，比如你们日志比较多，存储有特异性（管道到某个公司内部的采集系统，二进制压缩存储等），高吞吐量（需要单独设计缓存区），复杂的上下文打印这些功能，只能如果架构师在推广一个 sdk 的时候无法说出理由，大概率就是一个 kpi 产物了
|
 |
40
ghost3281 14 小时 54 分钟前
可能是为了方便扩展？比如后续收集日志进行统计分析之类，自动收集 crash 等等
|
 |
41
Bromine0x23 14 小时 53 分钟前 1
|
 |
42
MJTest 14 小时 52 分钟前
线上出问题的时候动态修改 log level?
|
 |
43
rockdodos 14 小时 51 分钟前
脱裤子放屁
|
 |
44
qdz 14 小时 49 分钟前
好处是不用每个类定义 log 对象？没感觉有其他啥好处，新项目改就改了吧，旧项目让他自己改
|
 |
45
yc8332 14 小时 48 分钟前
这个就是统一日志格式吧。。做日志搜集的时候方便，不然如果每个人写一个格式怎么解析
|
|
46
lucasdev 14 小时 48 分钟前
@unknown404 #26 如果是其他库或许可以这么说，但是 slf4j 出了 18 年了，在 mvnrepository 它是
#2 in MvnRepository #1 in Logging Frameworks Quartz 、Camel 、Akka 等有多少库使用了 slf4j 至于各种日志扩展，通过 Coverter 、Appender 等都可以实现，提供 sdk 引入即可，不需要侵入代码 |
 |
47
kneo 14 小时 46 分钟前
非要说好处就是可以强制调用者提供一个代码。非要说必要性那肯定是没有。可能这人岁数比较大，旧项目里代理的习惯。
|
 |
48
daybreakfangyang 14 小时 45 分钟前 via Android
不定规范，相当于在一坨💩山旁再拉一坨
|
 |
49
bk201 14 小时 45 分钟前 1
日志收集不是靠入侵业务代码实现的吧。我个人觉得日志用 util 类封装，然后放入业务代码里是很垃圾的做法。一方面要大批量改 log.info 代码，另外一方面后续接受的人并不会明白这个做法，增大代码 review 复杂度以及后续接收复杂度。po 主既然讨论了，能否把架构师的理由说出来听听。单纯统一入口，便于以后扩展不是理由，slf4j 已经足够抽象化。提出一个方案，必然是解决某个痛点，而不是过度设计
|
 |
50
chendy 14 小时 40 分钟前 1
从工作的角度，人家说啥就整啥就完事了
从经验的角度，我们也封了，但是总体来说 API 没啥变化，logger 看上去还是那个 logger 但是差了一些逻辑，直接出新 API 不是什么好文明 从自己的角度，应付过去就完事了，别耽误下班别耽误发工资就行 |
 |
51
Mikukko 14 小时 40 分钟前
个人感觉目前看是为了规范，保不齐后面就变成新的屎山
|
 |
52
k9982874 14 小时 39 分钟前 via Android 2
封装 LogUtil 很难理解吗？
封装 log 是统一格式，数据脱敏，数据清洗，大数据分析的第一步啊。 你只看你自己的业务，你们公司还有别的业务，其它语言写的平台吧，没有 slf4j 怎么办？ 即使有 slf4j 开新项目每次都复制模板？模板分叉了怎么办？哪个模板是最新的？ 天天制造屎山，还天天骂屎山 |
 |
53
SmiteChow 14 小时 36 分钟前
你不改怎么体现他的价值，他不给你提需求怎么体现你的价值？
|
 |
54
securityCoding 14 小时 32 分钟前
存粹是菜
|
 |
55
cloudzhou 14 小时 29 分钟前
没什么好处，并且代码很难看，统一入口不是这么个统一法
|
 |
56
RandomJoke 14 小时 28 分钟前 1
封装很常见，但是自己封装一个 Util 不常见，一般对日志有要求的，那么就基于 sl4j 做一个专门的 factory ，让业务无痛切换，底层实现格式化
|
|
57
neocanable 14 小时 27 分钟前
@k9982874 +1
|
|
58
bk201 14 小时 25 分钟前 1
@k9982874 你说的这些其他日志框架都实现了，而且性能更好，完全没必要自己造轮子。数据脱敏，数据清洗，大数据分析也不靠入侵业务代码实现，Logstash 、Fluentd 。多语言、多平台靠使用统一的日志收集平台 ELK 。LogUtil 这种入侵业务代码的非业务代码才会造成屎山，让人摸不着头脑。
|
|
59
lucasdev 14 小时 22 分钟前
@k9982874 1. slf4j 门面和 logback 等实现提供的扩展性都可以做到，楼主也说了，这些不是问题。
2. 每个语言有自己的最佳实践，别的语言或许封装一个 LogUtil 更为合适，但 Java 没必要。即使封装了 LogUtil ，也应该允许让其作为 slf4j 的实现，而不是不允许使用 slf4j 直接打印日志。此外，不同平台的日志不一定是统一管理。 3. 不存在模板复制的问题，安全、日志相关的自定义 sdk 使用 snapshot ，每次从 mvn repo 拉取最新版本。 |
 |
60
wangyzj 14 小时 17 分钟前
没啥毛病
理论上一些高阶功能无法走扩展，尤其是公司内部的一些基础设施集成 对于用户来说最简单的方法集成公司现有平台是最好的改造方向 想法是好的，但得把功能点先列出来 这种东西作为基础设施一环，想不清楚就是一坨，想清楚了整个公司数据一致性都会提高 你老板如果写不出来具体 feature 可以给方向 但感觉他也不太懂 |
 |
61
sxms77777 14 小时 16 分钟前
1. 以后换了日志框架，业务层不会有任何修改
2. 单元测试方便 mock 3. 模糊业务对细节的了解，防止他们使用一些不科学的 api |
 |
63
jackwang123 14 小时 14 分钟前
感觉收益不大，完全不需要这样做，大面积推广一个东西，必须有充分的理由和解决实际问题为目的。
|
 |
64
cccvno1 14 小时 13 分钟前
打工混日子你和 leader 较什么真呢，他最起码知道 logutil 不会出大问题，技术选型肯定选自己熟悉的。
|
 |
66
kinkin666 14 小时 11 分钟前 1
统一成一个不用动脑的样子不好吗，不然
private static final java.util.Logger LOGGER public final static slf.Logger logger private logback.Logger loger private log4j.logger log 更爽吗？虽然最后都是 logback |
 |
67
dxddd 14 小时 9 分钟前 2
绝对有好处啊。结合调用链，有利于跨平台日志收集、分析、追踪，不过前提是，你公司的得有这些基础设施。
|
 |
68
fpure 14 小时 8 分钟前
不过说实话，我还挺喜欢 LogUtil 这种静态工具类打印日志的用法，不需要在类里面专门声明一个变量，免得老是没用上然后报 unused warning
|
 |
69
ChefIsAwesome 14 小时 7 分钟前
多干点活，不然天天没事，把你们裁了。这叫供给端改革，不用管消费端需不需要。
|
 |
70
CloveAndCurrant 13 小时 59 分钟前
不但毫无意义，反而会增加定位难度，日志自动携带的代码，类等信息已经方便定位了，加"codexxx"这种需要人为手动填写，全靠人为约束的东西，只会增加日志定位的复杂度。
|
 |
71
COW 13 小时 57 分钟前 via Android
那你就封装 slf4j ，把 code 码注入进去要求必传参数就好了呗，反正 slf4j 就是抽象出来的，你上面多抽象一层。
|
|
72
lucasdev 13 小时 55 分钟前
@bk201 #65 这个帖子挂在"程序员"节点下，而不是"Java"节点下，感觉很多回复是对 Java 生态不太了解。看了你的几条回复，我和你的观点是比较一致的😁
|
 |
73
meeop 13 小时 54 分钟前
挺好的，但是如果你是业务团队，要提要求：
1 兼容目前 slf4g 所有 api ，业务侧无改动成本 2 如果因为 logUtil 导致的 bug 和故障，要架构师负责 |
 |
74
git00ll 13 小时 51 分钟前
哈哈习惯就好。jsonutil ，datautil ，redisutil ，cacheutil ，stringutil ，lockutil 还少吗
|
 |
75
lyxxxh2 13 小时 47 分钟前
你用其他方法打印日志,不就是找喷。
|
|
76
lyxxxh2 13 小时 44 分钟前
扩展也可以理解。
后面可能考虑,丢 es 其他产品的日志呢,或者更加自定义的操作。 |
|
77
lucasdev 13 小时 34 分钟前 1
楼主可以问问 AI ，我把问题直接丢给了 gemini 2.0, claude 3.5 sonnet, gpt-4o ，似乎都更推荐 SLF4J + Logback
  |
 |
78
ZeroDu 13 小时 34 分钟前
很多人可能不了解 java 生态下的 SLF4J ，什么动态日志级别，源码级别的日志过滤，这些都是自带的。相比其他语言来说真的是很完善了。
|
 |
79
zhady009 13 小时 30 分钟前
@git00ll 完全不能理解这种行为，库都提供好了非得自己再包一层然后弄成 static ，然后 util 对外暴露的 api 还更少了想用的时候又自己加一个方法。
|
 |
80
ldyisbest 13 小时 29 分钟前 3
职业生涯最重要的一课是，你需要认识到，你工作的目的不在于使得公司的客户满意，而在于使得那些控制你的加薪、奖金和晋升的人满意。
|
|
81
CloveAndCurrant 13 小时 25 分钟前
@meeop 你想多了，出了事架构师不可能负责的，logUtil 又不是架构师开发的，是架构师让你开发的，“不是我领导无方，而是你能力不行”。
|
 |
82
dcsuibian 13 小时 21 分钟前
假设确定了要写，那么大概有两种方案。
一、第一种方案，就是 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 ，让他解决 |
 |
83
YiXinCoding 13 小时 21 分钟前
这波架构师在大气层啊，这样大家都有活干，有绩效，对项目影响又不大。
防御性编程，如果再加上不写文档，Code 自己拿小本本记着，那是绝杀。 换别人排查日志定位不到问题，自己一看就能定位，建立壁垒，避免了被取代裁员。 （透过现象看本质，到了这个级别，追求的不是什么扩展性和实用性了，而是利益了） |
 |
84
xiangbohua 13 小时 6 分钟前
我觉得还是有好处的，只是是什么阶段什么时候做合不合适的问题。
也不要觉得做这个事情的目的想的那么功利，本来加薪就是要做事情。（前提是别搞幺蛾子比如大家明明忙不过来还要搞这种事情） 是真的有些人是想在代码上面有写追求的，哪怕公司没有加薪计划。 所以遇到这种事情，你不明白的话就问问他这么做的目的，让他给你解释解释，相当于请教一下（也可以学学领导的思维方式，也有好处），如果他跟你解释了你还是不能理解，那就问问他应该怎么实现，然后按照他的想法去实现就行，退一万步讲，写代码的写什么代码不是写？ 我主要还是说这件事情本身，如果做这个事情的过程比较恶心，那我觉得是另外一个范畴的问题了。 |
 |
85
zjiajun 12 小时 59 分钟前
站在顶层看，封装是没任何问题的，但也不一定是要封装的，封装后的优点如下：
- 统一日志框架版本。举例，log4j 漏洞升级版本，那就不用每个项目都修改一遍了 - 统一定义日志格式，方便搜集/格式化/分析/告警/数据看板等等 - 并不是所有人都知道 slf4j 是门面，有的应用日志框架实现是 log4j2 、有的是 logback ，当然统一最好啦 - 增强 code 我理解为，提升可维护性 |
 |
86
ffyyhh 12 小时 54 分钟前
现在你们有做日志采集吗，比如采集槽 ELK ，如何有的话，统一日志是有必要的
|
 |
87
liberize 12 小时 54 分钟前 via Android
新项目可以理解，改现有的没有必要
|
 |
88
MoYi123 12 小时 48 分钟前
个人经验, 工作中看到 “封装” 这个 2 个字就没好事.
|
 |
89
zizon 12 小时 43 分钟前
你的 slf4j 方案有办法让人不带上 code101 就编译不了么?
|
 |
90
nl101531 12 小时 36 分钟前 via iPhone
统一是好的，遇到过匿名化诉求，这个时候统一好处就来了
|
 |
91
leconio 12 小时 14 分钟前 via iPhone
新需求，把所有 info 日志加埋点。or 这个日志性能太差了，灰度换其他的。评估下工作量
|
 |
92
highkay 11 小时 59 分钟前
讲不清楚真正的具有说服力的优点的基本上说明没啥水平。统一日志（用来做分析）和你用的 log 封装根本没有直接关系，那主要是数据质量问题。
|
 |
93
Mandelo 11 小时 40 分钟前
搞清楚自己的定位,就是个干活的
|
 |
94
xuanbg 11 小时 39 分钟前
我司不规定日志实现，只规定日志格式，还必须是结构化的日志，不允许平铺直叙打日志
|
 |
95
iyaozhen 11 小时 32 分钟前
LogUtil.info ，我倒没啥意见，我们公司几千个研发，也是这么干的。当然我们是 Go ，没有 slf4j 这类事实上标准规范。但其实不关心 LogUtil 底层是咋实现的，只是打个日志，你可以在你自己的框架里面包一下（用起来还是 log.info ）
好处前面很多人也提过了，日志脱敏、存储的统一性。虽然有点搓，但也无伤大雅。 不过肯定有性能的要求，开发 LogUtil 的团队需要给出性能报告，以及承担相关责任（比如日志库 panic 了，平台上查不到日志了） 我倒是反对加上 code101 ，这种纯沙币的行为，完全不可控，很容易就重复了，还不如直接记录文件名+行 |
 |
96
KIDJourney 11 小时 26 分钟前 1
已经有 TCP 了，为什么大家不用 TCP 实现一切，还要在他上面发明个 HTTP ？明明什么问题都没解决
|
 |
97
clf 11 小时 22 分钟前
不是很好……统一的话直接在框架里下毒就行。我们就是这么干的。提供统一的 logback.xml ，然后各个实现类里自己引入 org.slf4j.Logger
反倒是有副作用？不知道怎么封装的，一般现在日志前面会有一个缩略的日志打印的类的类名。不知道他封装后是不是丢了。。。 |
|
98
clf 11 小时 20 分钟前
如果不是通过框架全局做单纯用 Util 封装的话，封装后还会有几个问题：
1. IDE 的括号和变量个数是否匹配的检查不会生效了。 2. 其他第三方库并不会按照你们的规范来…… |
 |
99
woodfizky 11 小时 20 分钟前 1
统一入口没毛病，日志 code 最好有个可扩展的枚举类之类的东西去约束。
你是不知道没统一日志工具类的情况，对本来各自为战的各个开发负责的各个不同风格的项目，统一做日志整改有多困难。 统一的好处就是好管理，日志工具也可以集成类似响应时间或者特定事件的监控，哪天公司要求对某些事件做监控报警了，限期做改造，然后你发现项目张三两个李四三个，却没用到统一的日志工具，整改起来你就头疼去吧。 有些日志侵入业务是因为一开始对日志没要求，或者说一开始业务没考虑日志和监控的需求，但是不代表这需求不合理。 |
 |
100
yor1g 11 小时 13 分钟前
人家重点是那个 code 🤣 你解决不了那个 code 就无法说服他
|
Select Language