1. 一个框架停更引发的技术选型焦虑

前几天在技术群里看到有人转了一篇帖子，标题大意是某个Java生态的AI框架停止维护了，底下评论区一片哀嚎，有人说"Java在AI时代彻底掉队了"，有人说"赶紧转Python吧别犹豫了"，还有人翻出几年前"Java已死"的老梗重新炒了一遍。我当时正在用Java写一个对接大模型接口的服务端模块，看到这些讨论的第一反应是：又来了。

这种焦虑每隔几年就会来一轮。当年Node.js火的时候有人说Java要完，Go语言崛起的时候又有人说Java要完，现在大模型浪潮来了，同样的剧本再演一遍。但如果你真的在一线写过生产代码，就会发现一个很朴素的事实：技术选型从来不是看哪个语言上热搜最多，而是看你的业务场景、团队能力和运维体系能不能接得住。

我自己过去一年多的时间里，陆续用Java做过好几个和大模型相关的项目——有给内部系统加智能问答的，有做文档批量摘要的，也有把大模型能力嵌入到现有业务流程里的。这些项目没有一个是"纯AI项目"，它们本质上还是业务系统，只是多了一个调用大模型API的环节。在这个前提下，Java不仅没有拖后腿，反而在很多方面比Python更省心。

这篇文章想聊的不是"Java和Python谁更好"这种口水话题，而是想从一个实际写代码的人的角度，把下面几件事说清楚：一个框架停更到底意味着什么、Java对接大模型的主流路径有哪些、不同路径的取舍逻辑是什么、以及在实际项目里我踩过哪些坑。如果你也在纠结"Java做AI到底行不行"，希望这篇内容能帮你把思路理清楚。

2. 框架停更这件事，到底影响了什么

2.1 停更不等于不能用，但要分清"停更"的几种情况

很多人看到"停更"两个字就慌了，其实这个词涵盖的情况差别很大。我一般会把它分成三类来看：

第一类是彻底归档。仓库标记为只读，Issue和PR都不再处理，官方文档也不再更新。这种情况下，如果框架本身功能已经稳定，你继续用其实问题不大，但一旦遇到新版本依赖冲突或者安全漏洞，就只能自己动手改。

第二类是维护模式。官方明确说不再加新功能，但会修关键bug和安全问题。这种状态其实是最常见的，很多成熟框架最后都会走到这一步。对于生产项目来说，这种状态反而是可以接受的，因为你要的本来就是稳定而不是天天变。

第三类是转移或合并。原来的项目不再独立维护，但核心能力被合并到了更大的项目或者由社区接手。这种情况其实不算坏事，只是换了个地方继续发展。

我见过太多人把这三类混为一谈，一看到"停更"就急着迁移，结果花了两周时间把项目从一个框架搬到另一个框架，搬完之后发现新框架的文档还不如旧的清楚，社区活跃度也就那样。迁移的成本往往被严重低估，而停更带来的实际风险往往被严重高估。

2.2 真正该担心的不是框架，是你把多少业务逻辑绑在了框架上

我复盘过自己做过的几个项目，发现一个规律：框架停更带来的痛苦程度，和你对框架的耦合深度成正比。

如果你只是用框架提供的HTTP客户端去调大模型的REST接口，那框架停更对你几乎没影响，你随时可以换成自己写的工具类或者换个HTTP库。但如果你把提示词模板、对话记忆管理、向量检索、工具调用编排全都建立在某个框架的抽象之上，那迁移起来就很痛苦了。

所以我的做法一直是：在业务层和框架层之间留一层薄薄的适配层。具体来说，我会定义自己的接口，比如一个ChatService接口，里面就几个方法——发消息、拿回复、流式输出。然后用框架去实现这个接口。哪天框架不行了，我换一个实现类就行，业务代码一行不用动。

这个思路听起来很简单，但实际做的时候很多人会偷懒，直接import框架的类到处用。等到要换的时候才发现，框架的类已经渗透到了Controller、Service、甚至实体类里。这时候再想抽离，工作量就大了。

2.3 从"框架依赖"转向"协议依赖"的思路转变

这两年我越来越倾向于一个原则：依赖协议，而不是依赖框架。

大模型的调用本质上就是HTTP请求加JSON，流式输出本质上就是SSE或者WebSocket。这些都是标准协议，不会因为某个框架停更就消失。你只要把协议层面的东西搞清楚，用什么语言、什么框架都是次要的。

举个例子，流式输出这块，很多框架帮你封装好了，你调一个方法就能拿到一个Flux或者Stream。但如果你自己用Java的HttpClient去发请求，处理SSE的data:行，其实也就几十行代码的事。我后来干脆自己写了一个轻量的SSE解析工具，不依赖任何AI框架，反而更可控。

我的经验是：越是底层的、协议层面的东西，越值得自己掌握。越是上层的、编排层面的东西，越可以交给框架。因为底层协议稳定，上层编排变化快。

3. Java对接大模型的几条主流路径

3.1 直接用HTTP客户端调REST接口

这是最朴素也最可控的方式。大模型服务商基本都提供REST接口，你用Java的HttpClient、OkHttp或者Spring的RestClient都能调。

我现在的默认选择是JDK自带的java.net.http.HttpClient，原因很简单：不用引额外依赖，JDK 11以上就有，而且支持异步和流式。下面是一个调用对话接口的简化示例：

HttpClient client = HttpClient.newHttpClient(); String requestBody = """ { "model": "your-model-name", "messages": [ {"role": "user", "content": "用一句话解释什么是向量数据库"} ], "stream": false } """; HttpRequest request = HttpRequest.newBuilder() .uri(URI.create("https://your-api-endpoint/v1/chat/completions")) .header("Content-Type", "application/json") .header("Authorization", "Bearer " + apiKey) .POST(HttpRequest.BodyPublishers.ofString(requestBody)) .build(); HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.body());

这种方式的好处是完全透明，出了什么问题你一眼就能看到是请求体不对还是响应解析错了。坏处是重复代码多，每个接口都要手写请求构造和响应解析。

我的做法是封装一个通用的LlmClient，把鉴权、重试、超时、日志这些横切关注点统一处理掉，业务层只传提示词和参数。这样既保留了可控性，又避免了重复劳动。

3.2 用Spring AI这类框架做编排

Spring AI的思路是把大模型调用抽象成Spring风格的API，让你用ChatClient这样的对象来发消息，用Advisor来做拦截和增强，用VectorStore来做向量检索。如果你本身就是Spring技术栈，上手确实快。

但这里有个现实问题：Spring AI本身也在快速演进，API变动比较频繁。我去年写的一段代码，今年升级版本之后编译不过了，因为几个核心类改了包名和方法签名。这不是Spring AI独有的问题，所有快速迭代的框架都有这个毛病。

所以如果你打算用这类框架，我的建议是：

• 锁定版本，不要盲目追新
• 在适配层里用它，不要让它的类扩散到业务代码
• 关注它的发布节奏，如果连续几个版本都是破坏性变更，就要考虑是不是该换条路了

3.3 自己搭一套轻量编排层

这是我目前最推荐给中小团队的方式。核心思路是：不引入重型框架，自己写一层薄薄的编排逻辑。

具体来说，你需要的东西其实不多：

这套东西加起来可能也就一两千行代码，但完全在你自己的掌控之中。哪天某个服务商的接口变了，你改一个类就行。哪天想换个模型，改个配置就行。

我做过一个对比：用重型框架搭一个问答Demo，大概半天能跑通；自己写轻量编排层，大概两天能跑通。但到了第二个项目、第三个项目的时候，轻量层的复用成本几乎为零，而重型框架每次都要重新踩一遍版本兼容的坑。

3.4 三条路径的取舍逻辑

到底选哪条路，我一般看这几个维度：

团队规模。三五人的小团队，自己写轻量层更划算，沟通成本低，改起来快。几十人的大团队，可能需要框架来统一规范，不然每个人写的风格都不一样。

项目数量。只做一个项目，用框架快速出活没问题。要做一系列项目，轻量层的长期收益更明显。

迭代频率。如果业务需求变化快，需要频繁调整AI相关的逻辑，那可控性比开发速度更重要。

运维能力。自己写的代码出了问题自己修，用框架出了问题要么等官方要么自己啃源码。如果你的团队没有啃源码的能力，那选框架要慎重。

4. 实际项目里踩过的坑和应对方案

4.1 流式输出在网关后面的缓冲问题

这个坑我踩了两次，第一次排查了大半天。

现象是：本地测试流式输出一切正常，字是一个一个蹦出来的。但部署到生产环境之后，用户看到的是一大段文字突然全部出现，完全没有流式的效果。

一开始我以为是代码问题，反复检查SSE的解析逻辑，没发现问题。后来才想到，可能是中间的网关或者反向代理做了缓冲。果然，运维那边确认，接入层默认开启了响应缓冲，会把小的数据块攒到一起再发出去。

解决办法有两个：一是在网关配置里关掉缓冲，二是让服务端在响应头里明确告诉中间层不要缓冲。我两个都做了，双保险。

// 在流式响应的Controller里设置响应头 response.setHeader("Cache-Control", "no-cache"); response.setHeader("X-Accel-Buffering", "no"); response.setContentType("text/event-stream;charset=UTF-8");

这个坑的教训是：流式输出涉及的不只是你的代码，还有从服务端到用户浏览器之间的每一层。排查的时候要从头到尾捋一遍链路，不要只盯着自己的代码看。

4.2 超时设置：连接超时和读取超时要分开配

大模型接口的响应时间波动很大，有时候两秒就返回了，有时候要等十几秒。如果你只配一个总的超时时间，很容易出现两种情况：要么正常请求被误杀，要么异常请求卡死线程。

我的做法是分开配置：

• 连接超时设短一点，比如5秒。连不上就赶紧失败，不要耗着。
• 读取超时设长一点，比如60秒甚至120秒。因为模型生成内容确实需要时间。
• 整体超时再设一个上限，比如180秒，防止极端情况。

HttpClient client = HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(5)) .build(); HttpRequest request = HttpRequest.newBuilder() .uri(URI.create(endpoint)) .timeout(Duration.ofSeconds(120)) .POST(HttpRequest.BodyPublishers.ofString(body)) .build();

另外，对于流式请求，读取超时的含义和普通请求不一样。流式请求是持续有数据回来的，只要还有数据在传输，就不应该触发超时。这时候你可能需要自己实现一个"空闲超时"的逻辑——如果超过一定时间没有任何数据到达，才认为连接出了问题。

4.3 重试策略：不是所有失败都值得重试

大模型调用失败的原因有很多种，有些可以重试，有些重试了也没用。

值得重试的：网络抖动、服务端5xx错误、限流返回429。这些通常是暂时的，等一会儿再试大概率能成功。

不值得重试的：参数错误返回400、鉴权失败返回401、请求体过大返回413。这些是你自己的问题，重试一百次结果都一样。

需要谨慎重试的：超时。因为你不确定服务端到底处理了没有。如果是计费接口，盲目重试可能导致重复扣费。

我一般用指数退避的方式做重试，第一次等1秒，第二次等2秒，第三次等4秒，最多重试三次。同时要设置一个总的时间预算，不能无限重试下去。

int maxRetries = 3; long baseDelayMs = 1000; for (int attempt = 0; attempt <= maxRetries; attempt++) { try { return doRequest(); } catch (RetryableException e) { if (attempt == maxRetries) throw e; long delay = baseDelayMs * (1L << attempt); Thread.sleep(delay); } }

4.4 提示词模板的版本管理

这个坑比较隐蔽，但影响很大。

一开始我把提示词直接写在代码里，用字符串拼接。后来需求变了，要调整提示词，我就改了代码重新部署。再后来发现不同场景要用不同的提示词，代码里到处都是字符串，改起来很容易漏。

后来我把提示词抽出来放到配置文件里，每个提示词给一个唯一的key，代码里通过key来引用。这样调整提示词不用改代码，而且可以做版本管理。

再后来我发现，光有key还不够，因为同一个key在不同时间可能需要不同的版本。比如A/B测试的时候，要同时跑两个版本的提示词。于是我又加了一层版本号，格式是key:version。

这套东西听起来有点过度设计，但如果你真的在生产环境里调过提示词，就会知道提示词的迭代频率往往比代码还高。把它当成配置来管理，而不是当成代码来管理，会省很多事。

4.5 对话历史的内存管理

做多轮对话的时候，对话历史会越来越长。如果不加控制，很快就会超出模型的上下文窗口，而且每次请求的token消耗也会越来越大。

我的做法是：

• 设置最大轮数。比如只保留最近10轮对话，更早的丢弃。
• 设置最大token数。估算历史消息的token总量，超过阈值就从头开始删。
• 重要信息摘要化。对于需要长期记住的信息，用模型生成一个摘要，把摘要作为系统提示的一部分，而不是保留原始对话。

这里有个细节：不要简单地按字符数来估算token。中英文的token比例差别很大，代码和自然语言的差别也很大。如果服务商提供了token计数接口，最好用接口来算。如果没有，就按一个保守的比例来估算，宁可多留余量。

5. 关于"Java还有没有希望"这件事的真实看法

5.1 语言只是工具，生态才是壁垒

我做了这么多年Java，最大的感受是：Java真正的价值不在于语言本身，而在于它背后那套成熟的工程体系。

你想想，一个生产级的服务需要什么？需要成熟的Web框架、需要连接池、需要事务管理、需要消息队列、需要缓存、需要监控、需要链路追踪、需要配置中心、需要服务注册发现。这些东西Java生态里全都有，而且经过了十几年的大规模验证。

Python在AI领域确实强，各种模型库、数据处理工具都是Python优先。但如果你要做一个面向企业用户的AI应用，后端还是得用Java或者Go来扛。Python更适合做模型训练和实验，不适合做高并发的业务服务。

所以我的看法是：不是Java有没有希望的问题，而是你要用Java做什么的问题。如果你要做模型训练，那确实应该用Python。如果你要做业务系统集成AI能力，Java依然是很好的选择。

5.2 大模型时代，后端工程师的核心竞争力在哪

这两年我明显感觉到，单纯会写CRUD的后端工程师越来越不值钱了。但这不代表后端工程师没有价值，而是价值点转移了。

以前你可能花很多时间在写SQL、调接口、处理各种业务逻辑。现在这些工作有一部分可以被AI辅助完成。那你的价值在哪里？

我的体会是，价值在于你能把AI能力可靠地、安全地、高效地集成到业务系统里。这需要你懂业务、懂架构、懂工程、懂运维，还要懂一点AI的能力边界。这些综合能力，不是会调几个API就能替代的。

具体来说，我觉得这几个方向值得投入：

• 提示词工程和上下文管理。怎么让模型稳定地输出你想要的结果，这是一门手艺。
• RAG系统的搭建和调优。怎么把企业私有知识有效地喂给模型，这里面有很多工程细节。
• AI能力的服务化封装。怎么把AI能力包装成稳定的、可观测的、可计费的服务。
• 成本控制和性能优化。大模型调用是要花钱的，怎么在效果和成本之间找平衡。

5.3 给还在观望的Java开发者的几条建议

如果你现在还在犹豫要不要往AI方向靠，我的建议是：

第一，不要急着换语言。你现有的Java技能是资产不是负债。把精力花在理解大模型的能力边界和工程实践上，比重新学一门语言划算得多。

第二，动手做一个完整的项目。不要停留在看文章、看视频的阶段。自己搭一个RAG系统，从文档解析、向量化、检索、生成到评估，完整走一遍。走完之后你对整个链路的理解会完全不一样。

第三，关注协议和标准。大模型领域变化很快，但底层的HTTP、SSE、JSON Schema这些东西是稳定的。把精力放在这些稳定的东西上，不要追着框架跑。

第四，保持对成本的敏感。很多做AI应用的人一开始不考虑成本，等到账单出来才傻眼。从第一天起就要有成本意识，知道每次调用大概花多少钱，知道哪些环节可以优化。

第五，别被焦虑营销带节奏。每隔一段时间就会有人出来说"XX已死""XX没希望了"，大部分都是为了卖课或者博流量。真正在一线写代码的人，没那么多时间焦虑，都在忙着解决问题。

6. 一个轻量级Java AI服务层的落地参考

6.1 整体结构设计

前面聊了很多思路层面的东西，这里给一个我实际用过的轻量级结构，供参考。

整个服务层分成四层：

• 接入层：对外暴露REST接口，处理鉴权、限流、参数校验。
• 编排层：负责提示词组装、对话历史管理、工具调用路由。
• 模型层：封装具体的大模型调用，屏蔽不同服务商的差异。
• 基础设施层：HTTP客户端、SSE解析、重试、日志、监控。

这个结构的好处是每一层职责清晰，换模型只动模型层，换编排逻辑只动编排层，互不影响。

6.2 核心接口定义

public interface LlmClient { ChatResponse chat(ChatRequest request); void chatStream(ChatRequest request, Consumer<String> onChunk); } public interface ChatService { String ask(String sessionId, String userMessage); void askStream(String sessionId, String userMessage, Consumer<String> onChunk); }

LlmClient是模型层的接口，不同服务商提供不同的实现。ChatService是编排层的接口，负责管理对话历史和提示词组装。

业务代码只依赖ChatService，完全不感知底层用的是哪个模型、哪个框架。这样哪天要换模型，只需要换一个LlmClient实现，业务代码一行不用改。

6.3 配置管理的关键项

llm: provider: your-provider endpoint: https://your-api-endpoint/v1/chat/completions api-key: ${LLM_API_KEY} model: your-model-name connect-timeout: 5s read-timeout: 120s max-retries: 3 retry-base-delay: 1s max-history-rounds: 10 max-history-tokens: 4000

这些配置项里，我觉得最容易被忽略的是max-history-tokens。很多人只设了轮数限制，但不同轮次的长度差别很大，光限制轮数不够。加上token限制之后，才能真正控制住上下文的大小。

6.4 监控和可观测性

AI服务的监控和普通服务不太一样，除了常规的QPS、延迟、错误率之外，还需要关注：

• token消耗量。按天、按接口、按用户统计，这是成本的主要来源。
• 首token延迟。流式输出场景下，用户感知到的响应速度主要取决于这个指标。
• 完整响应延迟。从发请求到收到最后一个token的时间。
• 重试率。重试率高说明服务不稳定，需要排查原因。
• 提示词命中率。如果用了缓存或者模板，统计命中情况。

这些指标我一般用Micrometer打点，然后接到Prometheus和Grafana上。不需要多复杂，但一定要有，不然出了问题两眼一抹黑。

7. 最后聊几句实在的

回到最开始那个问题：某个框架停更了，Java还有希望吗？

我的回答是：框架停更了，换个框架或者自己写就是了。Java有没有希望，取决于你用Java做出了什么东西，而不是取决于某个框架的维护状态。

这一年多我用Java做AI相关的项目，最大的体会是：真正难的不是调通接口，而是把AI能力稳定地、可控地、可负担地集成到业务里。这件事需要的是工程能力，不是语言偏好。Java在工程能力这块的积累，恰恰是它的优势。

如果你现在正在做类似的事情，或者正在纠结技术选型，我的建议是先把一个最小可用的链路跑通，然后根据实际遇到的问题来决定下一步怎么走。不要在一开始就纠结用哪个框架、哪个语言，先跑起来再说。跑起来之后你会发现，很多之前担心的问题根本不是问题，而真正的问题往往是你没想到的那些。

我在实际项目里还有一个习惯：每引入一个新的依赖或者框架，都会问自己一个问题——如果这个东西明天不维护了，我怎么办？如果答案是"那我就惨了"，那我会重新考虑要不要用它。如果答案是"换一个实现就行"，那我就放心用。这个习惯帮我避免了很多潜在的麻烦，也让我在选择技术方案的时候更加从容。