我太懂这种重复复制工具类的烦躁了——为单个类搭一套Maven仓库+版本管理确实有点杀鸡用牛刀，尤其是还要照顾非Maven项目的时候。下面给你几个更轻量化的解决方案，以及我认为的最优选择：

1. Gist + JitPack：零仓库成本的依赖共享 #

这应该是最简便的方案了，完全不需要单独创建Git仓库：

• 把你的字符串工具类（比如StringUtils.java）上传到GitHub Gist，创建一个公开的Gist即可。
• 访问JitPack，输入你的Gist ID（Gist页面URL最后那串字符），它会自动基于Gist的代码生成Jar包。
• Maven/Gradle引入：直接用JitPack提供的依赖配置，比如Maven的：

  <repositories>
      <repository>
          <id>jitpack.io</id>
          <url>https://jitpack.io</url>
      </repository>
  </repositories>
  <dependencies>
      <dependency>
          <groupId>com.github.你的GitHub用户名</groupId>
          <artifactId>你的Gist ID</artifactId>
          <version>最新提交的哈希值</version>
      </dependency>
  </dependencies>
  

• 非Maven项目：直接在JitPack页面下载生成好的Jar包，放到项目的lib目录就行。

优点：无需维护独立仓库，操作极简，支持所有主流构建工具，非Maven项目也能快速获取Jar。
缺点：版本管理依赖Gist的提交哈希，不如正式仓库的版本号直观；如果工具类需要添加依赖，Gist的支持有限。

2. 轻量仓库托管：GitHub Packages / GitLab Packages #

如果希望更规范的版本管理，又不想搭独立的Maven仓库，可以用代码托管平台自带的包管理功能：

• 把工具类做成一个极简的Maven/Gradle项目（只需要一个pom.xml或build.gradle，加上你的工具类），上传到GitHub/GitLab。
• 配置项目的包发布设置，把Jar包发布到GitHub Packages或GitLab Packages。
• 其他项目直接从这些平台引入依赖，非Maven项目也能直接从平台下载Jar包。

优点：版本管理规范，支持添加额外依赖，适合工具类未来扩展的场景。
缺点：需要创建极简项目，但比独立搭建Nexus等仓库简单得多。

3. Git子模块：源码级共享 #

如果你的项目大多是Git管理的，甚至可以直接共享源码，不用打包Jar：

• 把工具类放到一个独立的小型Git仓库（哪怕只有一个类）。
• 在各个需要用到的项目中添加这个仓库作为Git子模块：

  git submodule add https://github.com/你的用户名/字符串工具类仓库.git src/main/java/com/你的包名/utils
  

• 这样工具类的源码会直接嵌入到项目中，修改工具类后，所有引用子模块的项目都能通过git submodule update同步更新。

优点：不用打包，修改工具类后同步方便，非Maven项目也能直接用源码。
缺点：每个项目都要配置子模块，非Git项目无法使用；如果项目构建方式不同，可能需要调整源码路径。

最优方案推荐 #

如果你的工具类目前功能单一、短期内不会大幅扩展，Gist + JitPack绝对是最优选择——零额外维护成本，适配所有场景。等以后工具类需要添加更多功能、引入其他依赖时，再迁移到GitHub Packages这类轻量包管理平台也非常顺畅。

内容的提问来源于stack exchange，提问作者Leandro 86