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

[feitxue]

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

[sprite82]

@LeegoYih 别尬黑，还依赖冲突，hutool 就一个包，没有任何依赖

[coala]

算是问了我也想问的问题， 看了一圈我还是继续用吧。

hutool 大概是去年吧， 我当时用 JDK11 ， 发现支持不是特别好，刚去看了下已经说支持 JDK8+了。
还有就是 JSON 类的不是特别符合 Spring 那套规范吧， 序列化之类的我之前遇到不少问题。

很多小功能真的蛮方便。

[adoal]

不懂 Java 开发，从一个客户方的角度看，遇到的热衷使用 hutool 的开发方，开发能力和工程实施能力较为欠缺，技术水平令我无奈。

当然我知道这两件事在逻辑上既没有正向因果关系也没有反向因果关系。但就我遇到的小范围样本而言，有相关性。

[tairan2006]

我只用了 hutool-core ，主要补一些缺失的工具类。guava 和 apache-common 也经常用，反正混着来。

[ZeroDu]

楼里有些人真的是，舔呀； hutool 还是不错的；谈代码质量，我看国内那些大厂开源也不见得多好吧，bug 不也很多。闲包大这个更是无从说起

[ZeroDu]

@ZeroDu #65 一般都是合起来使用，apache guava 交叉使用；再配合 spring 里面自带的

[jdOY]

@liy333 没有代表 hutool 社区的立场，只是我个人说的"感觉不行不如考虑加入维护"，国内开源环境现在肯定是比不上国外，所以才更需要我们积极的参与，没必要国外的捧，国内的踩
@zpf124 认为哪个项目有什么问题，即使是提个 issue 吐槽也是促进社区活跃的行为，总比一味白嫖更好

[nothingistrue]

粗略扫了一下 hutool 的宣传理念和 hutool 的子项目分派，这玩意不是 Apche commons 、Google Guava 这样的基础工具包（或者更确切的说，JDK 扩展包），也不是 okhttp 、jackson 、netty 这样的专业领域工具包，而是像一个封装了 okhttp 、jackson 、netty 等各种工具的脚手架框架。

这玩意，用得人肯定不会少，但是你要去找推荐就基本不会有人推荐——要想用脚手架模式开发，为啥不用 PHP 呢。

[zpf124]

@adoal
其实是有关的，热衷于 hutool ，ruoyi ，mysql-plus 的大多数真的只是糊裱匠，“我只管最快速的干出来, 不出 bug 不就可以，工作而已何必较真”

就像做饭，有些人也推荐预制菜，买个半成品回家，这边一热那边撕开调料包倒进了不就好了，像方便面一样，犯得自己搞么，择菜洗菜自己弄半天还不如人家调料包香。

你说预制菜做的不好吗，其实 有一些真做的不错的，而且对于水平差的人，预制菜真的做出来的水平真的比它自己重头做好非常多。
但我不喜欢预制菜的统一口味调味料, 我觉得煎炸炒用同样的料包做出了的味道虽然也都好吃，但比不上我煎的时候配煎的料，炒的时候配炒的料做出来的香。

[easylee]

个人认为是一个不错的框架，提过几次 pr 和 issue 处理非常快。

好与不好，取决于使用者实质性使用行为。

[potatowish]

hutool 这种大而全的工具就适合快速开发上线的项目，没那么多讲究，功能开发出来就行。

[jeesk]

国产是原罪。

[zpf124]

@jdOY 如果你简单了解过相关工具的对比文章就会知道，apache commons 的 BeanCopy 效率差是大家都知道的事实，说这个事实就是为了告诫其他人在新项目里少用，而不是为了逼社区改。

人家不改是有充分的理由，就是为了兼容，为保证之前的使用者不会在更新后就出现不一致的行为。
你提 issue 也只会被人家指向最初那个不予修复的回答。


最后，使用和谈论本身就是一种促进社区活跃的行为。

如果你们的思想是 “用你们开源就是欠你们的，就是白嫖，就没资格评价这个开源东西好坏”，那建议你们别开源。

linus “fuck nvidia” 的时候也没给他们提 issue 更没有给他们写代码推 pr 。

[WesleyWong]

我就用 hutool-core 挺不错的。

[runzekk]

@zpf124 问题是你说客观事实了么？有分析么？有指标么？毫无理由的指责就是骂人。

你从哪里推出来的类比？我说不能说是指的 ‘自己觉得 hutool 不好不如考虑下加入开源一起维护‘，这句话，我认为这句话说的没错。
宁愿卑微如蝼蚁不要扭曲如蛆虫。
你不去给开源软件贡献，还在这无端指责，说你是开源软件的阻力，有错么？
还有我没艾特你把，你想插话就往上看看发言再说话，不然我都懒得理你。

[runzekk]

最可悲的是什么，没有想让其变好的想法，更不付诸实践，反而唾一口踩一脚，高高的往下俯视。

你配吗？

[zpf124]

@runzekk

“你不去给开源软件贡献，还在这无端指责，说你是开源软件的阻力，有错么？”
哇，那你们不应该做开源啊，你们应该去找人抱团做饭圈啊。

我说 spring 太臃肿的时候，我也拿不出证据了，毕竟我太主观了是吧， 我原来是开源的阻力了。
我说 apache commons 的 Bean copy 性能太差，还没给他们贡献过代码，那我是不是就应该是 Java 社区的罪人了。

另外建议你们别用现有的开源协议，你们得自己写一个 license 把你们的诉求也写进去，毕竟这些协议 “居然没有禁止别人在不提交代码的情况下评头论足，开源协议里就应该把这些阻碍社区发展的白嫖怪轰出去”

[runzekk]

作为一个 mybatis 和 seata 的贡献者，我说两点客观的评价。
1. hutool 是不错的，无所不包，用什么方法，用什么工具类，什么场景都能覆盖到。很多国外的开源脚手架，获取的结果往往还要自己转一下。
2. hutool 没有国内外的差别，比如时区问题。我之前写代码获取时间的时候，没注意使用到了 spring 中的一个时间类，是外国时间和国内时区不一样，导致一个 bug 。因为我觉得只是获取一下时间比较简单所以没测试。后来用国外的一定测一下。
3 。 抽象一点从设计层面来说，hutool 缺乏一些设计感，源代码比较冗余不够简洁，但是功能没问题。定位是一个工具类，从定位来看我觉得没啥大问题。工具类就是工具类，你不能指望他像 seata 和 mybatis 一样抽出来一个模型，然后围绕模型来迭代增加代码。
4. 还有说社区没有外国工具类火热的我就想笑，你但凡点开 github 看看社区都说不出来这种话。

[runzekk]

@zpf124 一句话，你也配点评 spring

[Vegetable]

我很难接受为了做一次 md5 就专门引入一个新的依赖的行为。