最近一段时间我刷开发者社区的时候反复看到一个词caveman。第一次瞥见我以为是哪个博主在聊穴居人的梗点进去才发现这是一个号称极简的Java HTTP客户端开源项目。让我产生兴趣的直接原因是它的一句话介绍——全宇宙最简单的Java HTTP客户端配合一个有点像原始人敲石头的Logo反差感拉满。我第一时间把它拉进了一个项目做验证折腾了两周结果是它确实比我预想的更接近返璞归真但它能成为热词这件事本身比库本身更值得聊一聊。这篇文章就是我实际体验后的完整拆解它是什么、怎么用、为什么零依赖还能干活、和主流方案差在哪、以及我踩过的几个坑。1. 穴居人式编程caveman这个热词是怎么在Java圈发酵的1.1 一次被样板代码气到的接口联调先说我为什么会关注它。前阵子我在做一个内部系统的数据同步模块需求本身很简单定时从一个第三方服务拉取JSON数据处理后落库。难点一点都不在业务上在于这个老项目的HTTP客户端基础设施早就没人维护了RestTemplate的配置散落在三个类里连接超时和读取超时写死在不同地方异常处理逻辑有四五套变体。我为了调通一个GET接口前前后后翻了一个下午的旧代码。这种经历凡是在Java后端待过一两年的人都不陌生。Java生态里做HTTP调用从来不是一个问题而是一堆问题——选哪个库、怎么配连接池、要不要引入spring-boot-starter-web、对象怎么自动转JSON...每一个选择题都有一堆默认值而这些默认值往往不是你想要的那个。所以当caveman这种号称不用配任何东西拿起来就用的库出现时我的第一反应不是这玩意能行吗而是怎么现在才有人做这个。1.2 项目名里的反差感最原始的写法解决最日常的问题caveman这个名字本身就是一个很好的传播抓手。它暗示的是你不需要一堆现代工具链才能生活一个原始的穴居人靠石头和木棍也能活下来。映射到编程语言里就是写个HTTP调用而已不需要那么多抽象和框架。这种命名策略在开发者圈子里天生具备话题性。项目方在介绍里反复强调自己极简、零依赖、不折腾连代码示例都故意做得像最原始的写法——不用Bean、不注入、不继承拿到坐标就能跑。相比于国内Java生态里默认Spring全家桶起步的氛围这种风格带来的反差感极其强烈所以在Reddit、X和不少技术公众号上都获得了大量转发。1.3 热度的实质大家不是在追捧一个库是在反思过度封装不过我仔细观察了一个月后发现caveman热度真正高的原因并不是它技术上有多少独到的创新——毕竟HTTP客户端都发展这么多年了底层能做的优化早就有人做了。它让人共鸣的是它精准踩中了Java开发者对过度封装的疲惫情绪。你看现在的Java服务端为了调一个第三方接口动辄引入包含几十个传递依赖的StarterAutoConfiguration自动加载一堆你用不上的组件类路径膨胀到肉眼可见地变慢。caveman反其道而行之不搞自动配置、不搞依赖注入、不搞注解处理器就是最简单的方法调用。它让很多人开始重新思考一个问题我是不是为了一个小的功能背上了一座本不需要的大山所以这篇博文并不是单纯吹捧这个库而是想把这种极简派的思维方式分享出来什么情况下极简是福什么情况下极简是坑以及我实测下来的真实体感。2. 三分钟跑通caveman从Maven坐标到第一次发请求2.1 pom.xml里只需要写一个依赖我们先从最实际的环节开始——让项目跑起来。这里我以我当时测试的1.x版本为例构建工具用MavenJDK至少需要11这个后面讲原理时会解释为什么。在pom.xml里加依赖dependency groupIdio.caveman/groupId artifactIdcaveman-client/artifactId version1.0.4/version /dependency就这几行。没有starter、没有parent、没有额外的BOM导入。我当时引入的时候特意刷新了一下依赖树传递依赖几乎为空jar包整体很小。如果你项目里用的是Gradle写法也差不多implementation io.caveman:caveman-client:1.0.4这里有个很舒服的细节因为它不依赖Spring所以你不需要考虑spring-boot版本兼容性也不存在Starter版本和主框架版本不一致这种破事。2.2 最简单的GET与POST写法装好依赖之后最简单的GET请求长这样CaveResponse response Caveman.get(https://httpbin.org/get).execute(); System.out.println(response.statusCode()); System.out.println(response.body());你没看错没有client.build()没有new Request.Builder()没有.build()链条。一个静态方法一个URL一个execute()完事。POST请求也不啰嗦直接传一个Map或者字符串体MapString, Object payload new HashMap(); payload.put(name, caveman-test); payload.put(ts, System.currentTimeMillis()); CaveResponse response Caveman.post(https://httpbin.org/post) .json(payload) .execute(); System.out.println(response.statusCode()); System.out.println(response.body());这里的.json(payload)会自动设置Content-Type: application/json并把Map序列化成JSON字符串。要注意的是这个序列化动作是caveman内部的极简实现复杂对象的序列化还是建议自己用Jackson/ObjectMapper处理这个我在第5章会展开。2.3 带上请求头、超时控制和错误码判断日常调用里光有GET和POST不够得有Header、超时和状态码处理。caveman的做法同样直白CaveResponse response Caveman.get(https://httpbin.org/headers) .header(Authorization, Bearer your-token) .header(X-Request-Id, UUID.randomUUID().toString()) .timeout(Duration.ofSeconds(10)) .execute(); if (response.isSuccess()) { String body response.bodyAsString(); System.out.println(body); } else { System.err.println(HTTP response.statusCode()); }.timeout()设置的是整个请求的超时时间底层直接透传给JDK的HttpClient。Header可以链式添加response.isSuccess()就是statusCode()在200-399区间为true简单直白。如果你的接口返回的是JSON也可以用.bodyAsJson()直接拿到一个MapMapString, Object data response.bodyAsJson(); Object origin data.get(origin);这一套下来新手从0到发第一个请求五分钟应该够了。3. 零依赖的秘密它凭什么不依赖就能干活3.1 站在Java 11 HttpClient的肩膀上很多人看到零依赖会觉得神奇但说白了caveman的底层起底层作用的是Java 11开始内置的java.net.http.HttpClient。这套标准库API支持HTTP/1.1和HTTP/2支持同步和异步请求支持超时控制、重定向策略、Cookie管理功能相当完整。caveman做的事情其实是更上面一层把HttpClient的样板调用代码包装成更友好的链式API。假如不用caveman纯用原生HttpClient写一个GET请求是这样的HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .build(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(https://httpbin.org/get)) .header(X-Request-Id, UUID.randomUUID().toString()) .timeout(Duration.ofSeconds(10)) .GET() .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.statusCode()); System.out.println(response.body());功能上没有任何问题但写起来确实枯燥。把这些重复劳动收敛到caveman后核心调用链就缩短到一两行。所以准确地说caveman不是一个全新实现的HTTP引擎而是一个建立在标准库之上的语义化壳层。这个设计聪明的地方在于标准库永远在JDK里它天然不会跟你说缺依赖。3.2 它主动砍掉的三类功能及其原因caveman最值得聊的设计是它克制的部分。我试用后发现它明确不包含这几类东西连接池调优底层HttpClient是有连接复用的但暴露出来的参数极少你想调keep-alive时长、连接池大小基本无从下手。重试与熔断机制没有内置的重试策略顶多你自己包装几层循环。复杂的拦截器体系像OkHttp的Interceptor那种AOP式的能力caveman没有。这显然是故意的不是为了省事而是为了守住极简这个定位。一旦加入了重试、拦截器、SPI加载这些机制配置项就会成倍出现库的重量感就上来了名字叫caveman就名不副实了。所以说caveman不是功能少而是选择了功能面积——它的卖点在于如果你面对的场景就是服务器之间简单调个接口它能让你的代码短到无法再短。你要是需要复杂的治理能力它本来就不是为你准备的。3.3 少一个依赖多出来哪些好处从工程角度说零依赖带来的收益在2025年的环境下越来越明显。首先是依赖漏洞扫描的范围缩小了现在很多企业的安全门禁会对每个传递依赖做CVE扫描依赖越多扫描告警越多被迫升级版本的可能性也越大。caveman没有任何传递依赖就少了一大片受攻击面。其次是编译和启动速度。我对比过在同一个老项目里引入SpringRestTemplate相关依赖和单独引入caveman的情况前者在依赖解析阶段花费的时间明显更长。当然单个库本身不至于产生肉眼可见的速度差异但一旦形成能少引就少引的习惯整个项目的jar体积和构建时长都会有改善。最后就是可维护性。caveman的API面很小团队成员看一遍示例代码基本就会用不太可能产生配置Bean A和Bean B互相引用这种老Spring项目里的诡异问题。对我这种经常接手别人代码的人来说少一种隐式配置就是少一颗雷。4. 和OkHttp、RestTemplate、原生HttpClient放一起比差在哪4.1 同一功能不同实现的代码量对比光说极简不够有说服力我拿同一个需求做了一次粗糙的对比发起一个GET请求带两个Header设置10秒超时打印状态码和响应体。我各写了一份代码结果数量级差异非常明显。方案代码行数大致额外依赖数量备注原生HttpClient20-25行0样板代码多但可控性强OkHttp15-20行若干传递依赖功能强大拦截器好用RestTemplate20行Bean配置需要Spring上下文传统老牌方案caveman5-8行0上手最快能力最基础这里我特意没有使用行数最少最好的刻板结论。RestTemplate虽然臃肿但在存量Spring项目里你把它换成caveman并不会立刻少维护多少代码反而可能打破团队既有的统一技术栈。OkHttp在需要细粒度拦截器、WebSocket的场景下依然是首选。caveman更像是一个轻骑兵适合快速验证、脚本化任务以及不想为一次简单调用拉入重依赖的场景。4.2 性能与线程模型的实际表现既然底层都是JDK 11的HttpClient你可能会问caveman和原生写法、甚至OkHttp在性能上差多少我的实测结果是没有可感知的差别。我跑了一个简单的测试程序并发20线程每个线程循环请求本机Mock服务100次统计P95耗时。caveman和原生HttpClient的P95差异在1-2毫秒以内完全属于噪声范围。OkHttp因为连接池复用策略更成熟在高并发下有微弱优势但也没有数量级的差距。需要特别说明的是线程模型。caveman的同步请求就是阻塞当前线程异步请求返回CompletableFuture底层用的是HttpClient的sendAsync。它没有自建线程池也不作额外调度。这意味着如果你的项目已经用了虚拟线程虚拟线程caveman配合起来没有冲突因为它不会像某些老库那样强行创建固定大小的平台线程池。4.3 它的适用边界什么场景该选什么场景别选试用两周后我给caveman画了一条不太精确的适用边界供参考适合用的场景内部工具类、一次性脚本、运维平台上的小功能追求写完就跑。不想为了一个接口调用引入整个Spring或者重量级HTTP库的项目。教学Demo、技术分享、开源组件的示例代码——它短到能完整塞进一张PPT。别用的场景需要对HTTP调用做统一拦截、日志、鉴权、熔断的微服务架构成熟项目这类需求还是交给完整方案。面向公网的复杂业务请求特别是需要自定义连接池参数、精细的超时链路、请求重放的场景。团队已有成熟的OkHttp/Retrofit技术栈且封装了很多内部工具类这时候引入新库反而增加认知负担。5. 实操两周后我踩过的四个坑5.1 BOM与父POM的版本锁冲突第一个坑是老朋友依赖版本管理。我们公司内部的父POM会统一管理各个库的版本如果你直接在子模块引入caveman而不加版本号就会因为父POM里没有这条依赖管理记录而解析失败。解决办法是在dependencyManagement里显式声明dependencyManagement dependencies dependency groupIdio.caveman/groupId artifactIdcaveman-client/artifactId version1.0.4/version /dependency /dependencies /dependencyManagement然后业务模块里再用没有版本号的写法引入。这个坑不怪caveman属于Java生态的通病但我在实测中确实因为它浪费了十几分钟提出来给大家避雷。5.2 JSON序列化得自己接一个顺手的小封装前面提到.json(payload)能自动序列化Map但我在测试中发现如果传入的是自定义POJO对象caveman的序列化器并不会自动处理你需要先把对象转成JSON字符串再传字符串进去。我最后在工具类里统一封装了一层public class HttpKit { private static final ObjectMapper MAPPER new ObjectMapper(); public static CaveResponse postJson(String url, Object body) { try { String json MAPPER.writeValueAsString(body); return Caveman.post(url).json(json).execute(); } catch (JsonProcessingException e) { throw new RuntimeException(JSON序列化失败, e); } } public static T T getAs(String url, ClassT clazz) { CaveResponse response Caveman.get(url).execute(); return response.bodyAsJson(MAPPER, clazz); } }这就是我说极简不等于没有功能而是把功能留在你手里的典型例子JSON转换这种最常用的能力它不给但接口设计上留了合理的接入方式。5.3 异步回调里的异常被静默吞掉Caveman.get(...).executeAsync()返回的是CompletableFutureCaveResponse。我在测试时有一处代码忘了加exceptionally回调结果请求目标服务临时不可用异常被吞掉后续逻辑什么都没收到排查了半天才发现是异步分支出了问题。后来我在所有异步调用处都统一加上了异常兜底Caveman.get(url) .executeAsync() .thenApply(CaveResponse::bodyAsJson) .exceptionally(ex - { log.error(异步请求失败, ex); return Map.of(error, ex.getMessage()); });这个经验其实对所有返回CompletableFuture的库都适用——异步链不挂兜底出错的时候会很安静调试成本高。5.4 高并发下的连接池行为caveman的底层用JDKHttpClient它底层里维护了连接复用机制默认允许的并发连接数上限在文档里写得比较含蓄。我在压测时发现并发开到100后部分请求的建立连接时间明显上升这是HttpClient连接池分配策略的表现不是caveman本身的bug。如果你在高并发下使用并且觉得连接建立耗时有异常一个可行的方案是把HttpClient实例显式传给Caveman进行构建caveman允许自定义底层Client并把连接池参数配置交给JDK层去调。极简的库不代表你不能在局部认真调优只是它默认帮你选了一个够用的配置。6. 最后说点心里话极简不等于万能两周用下来我对caveman的定位是它不是一个更优秀的HTTP客户端它是一个更轻的HTTP客户端。它的价值不在于性能比OkHttp快多少、功能比RestTemplate多多少而在于让你重新审视了一次我到底需要多少工具才能完成这个任务。我在实际项目里最终保留了caveman用于内部运维工具和脚本类功能核心业务的复杂调用还是走了团队既有的OkHttp体系。这个选择并不矛盾工具是拿来解决问题的不是拿来供奉的。当一个3行的请求代码能替代20行样板的时候少点负担挺好但当你需要重试、熔断、拦截器体系的时候也别为了极简硬撑着不用更完整的方案。如果你看到这里我建议你做的第一件事不是去重构项目而是打开一个空项目引入caveman用五分钟把一个你经常用到的第三方接口调通。那种把样板代码删掉之后的清爽感会帮你更清楚地判断你的项目里有多少复杂度是真实的有多少只是惯性。
