有看到好几个层主回复不建议使用 hutool 没看到具体理由

[feitxue]

特意单独开贴提问下
只有一个有具体讲到说是 hutool 整个引入太大了
其他几个没有讲到具体理由
是否遇到有什么大坑？
请大家不吝赐教
根据各位回复我需要评估下是否移除 hutool 的引用

[zjp]

不喜欢的原因：团队里总有人一股脑把 hutool-all 引进来
不需要的原因：Apche commons 、Google Guava 和 Spring Utils 足够了，代码质量也更高
之前对比过 hutool 和 Spring 查找 Class 的方法，Spring 覆盖的情况更全。明天开电脑看能不能找到详细的

[jdOY]

1.领导不让用或者领导不喜欢就不用
2.自己觉得 hutool 不好不如考虑下加入开源一起维护
3.团队有人乱引用 hutool-all 那应该是用规章制度去规范，不能怪工具吧？

[echo1937]

主要是 Apche commons 、Google Guava 功能已经基本满足了，这两个历史悠久（已经学过了，不用再付出学习成本，基本掌握了最佳实践），社区支持和代码质量经过更长的检验，所以我不推荐混用，但是不反对互相替换，统一规定就好。

[liy333]

在生产环境引进一个新的依赖库，需要考虑多个方面，比如社区活跃程度，代码质量，维护团队水平……像楼上说的，可以跟 Apche commons 、Google Guava 、Spring Utils 对比下。良好的社区氛围对于一个开源项目也很重要，至少没见过上面几个项目的社区会说出“觉得不好不如考虑下加入”这种 PUA 的话术

[GTim]

引入一个超级大的包，就为了使用哪几个方法

[potatowish]

禁止引入 hutool ，还有小众开发者发布的依赖包。Apache 、Google 、Spring 发布的工具包已经够用了，倒是公司的外包特别喜欢一股脑引入 hutool-all 这类的包。

[mineralsalt]

我就喜欢 hutool, 各种工具都有, 省心, 包能大多少

[RedBeanIce]

正方：省心什么都有
反方：代码行数越多，BUG 越多

[me1onsoda]

都干 Java 了，包大点有关系吗

[sleepybear1113]

Hutool 的 FileUtil 不建议使用。是针对 classpath 为基准的，如果走相对路径，比如 FileUtil.getPath("data/sqlite.db") 那么会在前面拼 classpath 路径，比如会有 xxxxx/target/class/data/sqlite.db ，而不是 xxxxx/data/sqlite.db ，其中 FileUtil.getPath 可能不一定有这个方法，因为很久不用了，为了举例所写的不知道是否存在的方法。

[cnzjl]

想到了之前不让用若依 ruoyi 的人，有个老哥单独开了个贴，列出了项目的问题

[Bingchunmoli]

00 后表示通常用 hutool ，common 和 guava 不熟，⁽⁠⁽⁠◝⁠(⁠ ⁠•⁠௰⁠•⁠ ⁠)⁠◜⁠⁾⁠⁾

[zjp]

@jdOY 是的 不喜欢只是一个主观感受
不影响团队决策

[sumarker]

看个人诉求吧
我觉得完全可以用
作为一个工具包全面肯定会有一个代价就是容易冗余
其他的包冲突 漏洞啥的 , 修修补补也没什么

[litchinn]

以 hutool 的活跃度来说，有什么坑也早就暴露出来被修复了
所以使用上肯定是没有问题的
问题在于：
1. 没有大厂背书，维护者水平良莠不齐，代码质量对比 guava 肯定是不够的，因此会让人担心未来会暴雷
2. 使用 all 包引入了很多不需要的内容，但是这对 java 用户特别是 spring 用户来说根本不算什么
推荐使用的理由是，足够全面，特别是在团队内有新手的情况下，遇到过很多新手也包括自己在新手时有一个毛病，在网上找代码然后复制到项目中，然后发现有类需要引入依赖，就直接在 maven 中引入了，最后导致一个项目最后把市面上几乎所有的工具类包都引进来，而明确指出工具类使用哪一个包有利于改善这一现象

[zjp]

#1 是查找 Method 的方法，对于以下的类
public class Stub {
public void a(Object o) {}
public void a(String o) {}
}
用 cn.hutool.core.util.ReflectUtil.getMethod(Stub.class, "a", String.class) 找到哪个方法只取决于上面方法定义的声明顺序
而 org.springframework.util.ReflectionUtils#findMethod 不会考虑参数的继承关系，只精确匹配
我觉得 Spring 的行为更合理，hutool 即使确实需要支持参数传递子类，也应该找到继承关系最接近的（就像 JVM 那样）

[wxw752]

没事，等 35 被退休就不用考虑这个问题了😁

[wangYQ]

我这做框架的人不喜欢，但是我需要其中一部分功能，我让他去实现，但是现实的不符合需求，最后也得让我引入，但是引也不能全引入，用哪个模块引哪个。

[zzNaLOGIC]

一个问题，你们项目包大是因为 hutool 么。

[Plutooo]

hutool 里面有个 StrUtil ，组内同事因为 veracode 扫描的原因升级了一下 hutool 的版本，代码中有使用到 StrUtil.split ，升级版本后编译不报错但是运行直接报错了。还有很多方法升级版本后编译都没法通过，排查着累后面一把梭换成了 Apache 的 StringUtils 了。国产开源总给我一种感觉，升级版本之后原先的能有一大堆不兼容的，不知道是不是我的错觉