Hutool工具的引用和使用

一、序言

  相信作为Java开发者基本上都使用过Hutool，对于这款工具，褒贬不一，有意见的部分开发者主要集中在过于臃肿、过于繁杂等问题。那我们今天就来简单介绍下引用和使用方法。
官方文档传送门：官方文档

我为什么选择Hutool？
我个人对于选择Hutool的主要原因，还是代码注释都是中文，自己找方法比较方便，像common-lang3这种的，对于英语堪忧的我，看起来还是很累的。

以下内容均来自个人使用习惯，示例环境为maven，仅供大家参考。

二、引入依赖

以下内容中${hutool.version}均为在pom.xml文件中properties定义的Hutool版本号。

2.1 传统方式

  我看到过很多同行引入Hutool都是全量引入hutool-all，然而实际使用中仅仅只是使用了几个小的工具类，然后抱怨框架过重，很多东西都用不着。

<dependency><groupId>cn.hutool</groupId><artifactId>hutool-all</artifactId><version>${hutool.version}</version>
</dependency>

  这样相当于引入了Hutool的所有模块，强烈不建议这样！！！

2.2 模块引入

  其实Java模块化的概念早就不是一个新的概念了，大家平时在Gitee或者Github上面看的开源工具类包，基本上都采用了分模块的方式。开发者在使用中，可以根据自己的需求引入相应的模块。
  举个例子，我们在开发中需要调用其他服务，以前大家都会选择HttpClient或者OkHttp之类的工具，这个时候我们可以使用hutool-http模块，可以满足绝大部分需求。

<dependency><groupId>cn.hutool</groupId><artifactId>hutool-http</artifactId><version>${hutool.version}</version>
</dependency>

  这样引入指定模块，包就会小很多，如果是单模块项目或者引入模块很少，可以使用这种方式。

2.3 import方式引入

  不知道大家有没有过这样的经历：项目比较大，开发人员也比较多，每个人开发一个模块，然后前期脚手架培训不到位，每个人都在引入工具包，尤其是版本有更新时，项目里相同工具包居然有好几个版本。

  或者说大家有没有喜欢用阿里云脚手架创建项目的？你会发现pom.xml的内容跟IDEA创建的项目引用SpringBoot的方式是不一样，他们就比较喜欢用import的方式进行依赖版本控制。

  如果大家能抽出一点时间简单阅读Hutool的文档，你就会发现它也有import的方式引入：

<dependencyManagement><dependencies><dependency><groupId>cn.hutool</groupId><artifactId>hutool-bom</artifactId><version>${hutool.version}</version><type>pom</type><!-- 注意这里是import --><scope>import</scope></dependency></dependencies>
</dependencyManagement>

***请注意：这里是dependencyManagement标签内，一般使用IDEA创建的项目是没有这个标签的，请在build标签上面完整复杂以上内容即可。

  引入以上内容后，再想引入模块就比较简单了：

<dependencies><dependency><groupId>cn.hutool</groupId><artifactId>hutool-http</artifactId></dependency>
</dependencies>

***请注意两点：①模块的引入是在dependencies标签内；②不需要写版本号！！！

三、使用问题

3.1 Hutool迁移组织问题

  半年前Hutool从Dromara组织迁移到Bugotech，有传言该项目已经被卖了。具体情况咱肯定是不知道，但Hutool确实更新了关于AI的功能（还有个平台），个人认为有商业化的倾向。
  不过，有一点是可以肯定的：目前我们使用的工具包肯定是不会收费的。所以，对于我们这种普通开发者来说，几乎没有影响。

3.2 Hutool版本问题

  目前Hutool的生产版本依旧是5.x.x，但是很早之前他就在做6.x版本，我也在项目中使用过几次，变化还是很大的，但是目前该版本已被放弃，所以我们就不对它做过多介绍了。
6.x已被放弃，请勿再使用！！！
6.x已被放弃，请勿再使用！！！
6.x已被放弃，请勿再使用！！！

  当Hutool进行组织迁移时，就说明将会进行7.x版本的开发，并且该版本支持JDK17+，应该是对y应的目前正在逐渐普及的SpringBoot3.x。截至目前，中央仓库已存在7.0.0-M1版本（测试版本），不过看起来更新速度并不是很理想，谨慎使用。
7.x版本测试阶段，谨慎使用！！！
7.x版本测试阶段，谨慎使用！！！
7.x版本测试阶段，谨慎使用！！！

我们公司目前使用的JDK21，hutool版本为5.8.38，基本没有不兼容的情况，所以准备升级到SpringBoot3的朋友不需要担心不兼容。

3.3 额外依赖引入

  Hutool在hutool-extra等模块主要是工具封装或门面封装，所以需要自己引入额外的依赖。这个时候需要注意两点：①别漏了额外依赖的引入；②注意额外依赖的版本要求，如果不确认，千万看文档。可以参考以下图片：

四、常见的几种工具包使用情况

  Hutool是一个非常好的工具，但不是说人人都必须要使用，每个项目leader都有自己的理解，我简单说几种碰到过的情况。

4.1 使用开源的工具包

  这种很常见，比如比较出名的Hutool和春哥的mica，这些工具内容多，也有大牛维护，还是非常不错的。这种方法的优点就是框架成熟、工具丰富，但是缺点也很明显，就是使用中需要自己翻文档找方法，大意的人还容易使用错方法。

对mica感兴趣的朋友可以点击：mica官方文档，该工具不仅用常用的字符串、集合等工具类，还有像验证码、定时任务等组件，非常牛！！！

4.2 自定义工具包

  很多有代码洁癖的技术leader会自己写工具包，比如我们常见的若依框架，主要是通过Spring、common-xx、自定义方法三种方式来完成，这种工具包不复杂，但是够用。不过缺点也很明显，工具较少，而且使用者少，很难保证没有bug。

4.3 放养式使用

  这种就比较尴尬了，就是项目组没有明确对工具包的使用。比如使用若依脚手架，有的人使用自带的工具类，有的人引入Hutool等第三方工具包，很是混乱。

五、写在最后

  工欲善其事必先利其器，作为一款成熟、丰富的工具包，我对Hutool的信任还是很强的，希望它能减少大家的工作。