1. 老项目接 Spring AI 为什么总卡在依赖和超时上
如果你手上有一个跑了三五年的 Spring Boot 老系统，JDK 8、Spring Boot 2.7.x、MyBatis 加 Oracle 的组合，现在产品突然说要加个智能问答或者智能客服，你第一反应大概率是「接个大模型 API 能有多难」。我一开始也是这么想的，结果从加依赖那一刻起就开始踩坑：启动直接NoSuchMethodError，好不容易跑起来了，流式输出又在前端卡到 15 秒超时，日志里全是Connection reset by peer。
这篇就聚焦两件事：Spring AI 接入存量老项目时的依赖冲突怎么排，以及流式响应超时怎么从根上解决。中间会给出可直接复制的pom依赖树处理方式、SSE 超时参数配置、线程池隔离方案，最后用 TaoToken 统一 Key/API 通道做一次连通性验证，确认你的改造链路是通的。
先说清楚适合谁看：你正在维护一个 Spring Boot 2.x 的老项目，想引入 Spring AI 但被版本断层卡住；或者你已经接上了，但流式接口在网关或前端频繁超时。这两种场景我都会给到具体命令和配置，不是泛泛而谈。
核心检索词先摆出来：Spring AI 依赖冲突排查和流式响应超时配置，这两个是整篇的主线。依赖地狱的本质是 Spring AI 1.x 要求 Spring 6.1+，而老项目锁在 Spring 5.3，传递依赖一交叉就炸。流式超时则是网络层、应用层、中间件三层超时没对齐，任何一层先断，前端就显示超时。
我试过的顺序是：先解决依赖能不能启动，再解决流式能不能稳定输出，最后才是 Prompt 和监控这些上层的东西。顺序反了会浪费大量时间，因为依赖没理顺之前，你连一个正常的请求都发不出去，根本没法验证超时问题。
下面按这个顺序展开，每一步都给可复制的配置和验证方式。
2. TaoToken 统一 Key 通道的前置准备
在动老项目代码之前，建议先把模型通道这件事独立出来验证。原因很简单：如果依赖冲突和网络问题混在一起排查，你分不清是 Spring 版本的问题还是 Key 通道的问题。用一个统一的 Key/API 通道先把「模型能不能通」这件事确认掉，后面改代码时心里有底。
TaoToken 在这里的角色就是统一通道：你不需要在项目里散落多个厂商的 Key，也不用为每个模型单独配一套 Base URL。官网入口是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ，API 地址是 https://taotoken.net/api ，注意 API 地址不带 UTM 参数，配置的时候别把查询串带进去。
前置准备分三步，都是几分钟能完成的：
第一步，拿到 Key。进入控制台创建 API Key，地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，创建后复制保存，后面配置里要用。Key 的权限和额度在控制台能看到，建议先建一个测试用的 Key，别直接上生产 Key。
第二步，确认你要用的模型 ID。不同模型在请求体里的model字段值不一样，这个值要和你后面 Spring AI 配置里的模型名对齐。可以先在模型对话页面手动发一条消息验证通道，地址是 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite ，发一句「你好」看有没有正常返回。这一步能排除掉 Key 错误、额度不足、模型名写错这类低级问题。
第三步，记下接入文档的位置，后面配 Spring AI 的 Base URL 和路径时对照着来，文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。文档里会说明兼容的接口路径，Spring AI 的 OpenAI 兼容模式需要把 Base URL 指到对应位置。
这里有个关键点：Spring AI 的 OpenAI starter 默认会拼接/v1/chat/completions这类路径，所以你的 Base URL 要配成https://taotoken.net/api，让它去拼后面的部分。如果你配成了带/v1的地址，很可能出现 404。这个坑我在验证阶段踩过，日志里是 404 而不是 401，很容易误判成路径问题。
把这三步做完，你手上就有了：一个可用的 Key、一个确认能返回的模型 ID、一份路径对照文档。接下来再回到老项目里改依赖和配置，出问题时就能快速区分是通道问题还是代码问题。
3. 可复制的依赖对齐与超时配置
这一节是整篇的核心，给的都是能直接粘进项目的片段。先解决依赖地狱，再解决流式超时。
3.1 依赖树分析与 BOM 对齐
老项目引入 Spring AI 后启动报NoSuchMethodError: org.springframework.core.io.Resource.getContentAsString，根因是 Spring AI 1.x 传递进来了 Spring 6.1 的spring-core，而你的项目锁在 Spring 5.3。两个版本的类同时存在，类加载器加载到旧版本就炸。
先看依赖树，把冲突暴露出来：
mvn dependency:tree -Dincludes=org.springframework -Dverbose输出里你会看到同一个groupId:artifactId出现多个版本，比如spring-core:5.3.30和spring-core:6.1.x同时被引。处理原则是：老项目不要强行升 Spring 大版本，而是把 Spring AI 的传递依赖排除掉，让它复用你现有的 Spring 5.3。
在pom.xml里对 Spring AI 的 starter 做排除：
<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-openai-spring-boot-starter</artifactId> <version>1.0.0-M4</version> <exclusions> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> </exclusion> <exclusion> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> </exclusion> </exclusions> </dependency>然后用dependencyManagement统一锁定 Spring 版本，确保全项目只有一个版本：
<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-framework-bom</artifactId> <version>5.3.30</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>注意 Spring AI 的某些版本对 Spring 6 有硬依赖，如果排除后编译报错找不到类，说明这个版本不兼容 Spring 5.3，需要换一个更早的 milestone 版本，或者把 Spring AI 的调用层单独抽成一个模块，用独立的类加载器隔离。模块隔离的配置如下：
@Configuration @EnableAutoConfiguration(exclude = { MybatisAutoConfiguration.class, DataSourceAutoConfiguration.class }) @ComponentScan(excludeFilters = @ComponentScan.Filter( type = FilterType.REGEX, pattern = "com\\.company\\.legacy\\..*" )) public class AiIsolationConfig { @Bean public Module aiModule() { return new SimpleModule("ai-module") .setClassLoader(AiIsolationConfig.class.getClassLoader()); } }3.2 流式超时的三层配置
依赖理顺后，流式接口的典型故障是：前端 15 秒显示超时，后台日志显示模型 8 秒就返回完了，但 TCP 连接在第 12 秒被断开。这是三层超时没对齐：Netty 的 readTimeout、WebClient 的 timeout、Nginx 的proxy_read_timeout。
先配应用层的 WebClient 超时，注意流式场景要按 chunk 设超时，而不是整个响应设一个总超时：
@Bean public WebClient aiWebClient() { return WebClient.builder() .baseUrl("https://taotoken.net/api") .defaultHeader("Authorization", "Bearer ${TAOTOKEN_API_KEY}") .clientConnector(new ReactorClientHttpConnector( HttpClient.create() .responseTimeout(Duration.ofSeconds(60)) .keepAlive(true) )) .build(); }流式请求单独设 chunk 超时和心跳：
public Flux<String> stream(String prompt) { return webClient.post() .uri("/v1/chat/completions") .bodyValue(buildRequest(prompt)) .retrieve() .bodyToFlux(String.class) .timeout(Duration.ofSeconds(30), Flux.just("{\"type\":\"timeout\"}")) .onBackpressureBuffer(1000) .retryWhen(Retry.backoff(3, Duration.ofSeconds(1))); }application.yml里把 WebFlux 和 Tomcat 的超时一起对齐：
spring: webflux: timeout: response: 60s codec: max-in-memory-size: 10MB server: tomcat: connection-timeout: 60s max-keep-alive-requests: 100Nginx 侧对应调整，proxy_read_timeout要大于你的 chunk 超时：
location /api/ai/ { proxy_pass http://backend; proxy_read_timeout 90s; proxy_send_timeout 90s; proxy_buffering off; proxy_cache off; }proxy_buffering off对流式很关键，开着缓冲会导致 SSE 数据被攒着一起发，前端看起来就像卡住了。
3.3 线程池隔离
老项目的 Tomcat 线程池是给普通 HTTP 请求用的，流式请求会长时间占用线程，容易把线程池打满导致整个服务不可用。给 AI 调用单独开一个线程池：
@Configuration public class AiExecutorConfig { @Bean("aiExecutor") public ThreadPoolTaskExecutor aiExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix("ai-exec-"); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }调用时指定这个线程池，别用默认的：
@Async("aiExecutor") public CompletableFuture<String> chatAsync(String prompt) { return CompletableFuture.completedFuture(aiClient.chat(prompt)); }到这里，依赖、超时、线程池三块配置就齐了。下一节验证请求能不能通。
4. 验证请求与成功结果
配置写完，先别急着接前端，用最小请求验证通道和流式是否正常。这一步能帮你把「代码问题」和「通道问题」分开。
4.1 用 curl 验证通道
先用命令行确认 TaoToken 通道本身是通的，把 Key 换成你自己的：
curl -X POST https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-3-5-sonnet", "messages": [{"role": "user", "content": "你好"}], "stream": false }'预期结果是返回一个 JSON，choices[0].message.content里有模型的回复。如果这里就报 401，说明 Key 有问题；报 404，说明路径拼错了，检查 Base URL 是不是多了或少了/v1。
4.2 验证流式输出
把stream改成true，观察是否逐块返回：
curl -N -X POST https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-3-5-sonnet", "messages": [{"role": "user", "content": "写一段100字的介绍"}], "stream": true }'-N参数关闭 curl 的缓冲，你能看到data:开头的行一块块刷出来。如果全部内容一次性出现，说明中间有缓冲没关掉，回去检查 Nginx 的proxy_buffering。
4.3 Spring 侧验证
写一个测试接口，确认 Spring AI 的调用链路是通的：
@RestController @RequestMapping("/api/ai") public class AiTestController { private final ChatClient chatClient; public AiTestController(ChatClient.Builder builder) { this.chatClient = builder .baseUrl("https://taotoken.net/api") .apiKey(System.getenv("TAOTOKEN_API_KEY")) .build(); } @GetMapping("/ping") public String ping() { return chatClient.prompt() .user("回复：pong") .call() .content(); } @GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<String> stream(@RequestParam String q) { return chatClient.prompt() .user(q) .stream() .content(); } }启动后访问/api/ai/ping，预期返回包含pong的字符串。访问/api/ai/stream?q=你好，预期在浏览器里看到 SSE 逐块输出，而不是等很久一次性出来。
成功结果的特征：ping接口 3 秒内返回，stream接口首字节在 1 秒左右出现，后续 chunk 间隔稳定。如果首字节超过 5 秒，回去看线程池和连接超时配置。
5. 本篇常见错误排查
这一节按真实报错来对照，都是我在改造过程中实际遇到的。
401 Unauthorized：Key 没配或配错。检查Authorization头是不是Bearer加 Key，中间有空格。如果是环境变量注入，确认变量名没写错，System.getenv拿不到会返回 null，拼出来就是Bearer null。另外确认 Key 没有多余的空格或换行，从控制台复制时容易带上。
404 Not Found：Base URL 路径拼错。Spring AI 的 OpenAI 兼容模式会自己拼/v1/chat/completions，所以 Base URL 应该是https://taotoken.net/api，不要再加/v1。如果你用的是自定义的 RestTemplate 直接调，那 URL 要写全https://taotoken.net/api/v1/chat/completions。两种方式别混。
local proxy failed / Connection refused：这类报错通常是本地网络或代理配置问题。检查你的application.yml里有没有残留的proxy配置，或者系统环境变量里有没有HTTP_PROXY。老项目经常在启动脚本里设了代理，AI 请求走代理就会失败。把代理配置清掉，直连通道地址。
reading choices 相关报错：一般是响应体解析失败。流式场景下，如果服务端返回的不是标准 SSE 格式，Spring AI 解析choices字段时会报错。先用 curl 确认返回格式，再检查你的produces是不是text/event-stream。另外max-in-memory-size太小也会导致大响应被截断，调到 10MB 以上。
OAuth / token 过期：如果你用的是需要 OAuth 的通道，token 过期会报这个。TaoToken 用的是 API Key 方式，正常不会出现 OAuth 报错。如果出现了，检查是不是误配了别的认证方式，把认证头统一成Authorization: Bearer <key>。
流式超时但后台显示已完成：这是最典型的。后台日志显示模型 8 秒返回完，前端 15 秒超时。按第 3.2 节的三层超时逐层检查：WebClient 的responseTimeout、Nginx 的proxy_read_timeout、前端的AbortController超时时间。三层里最小的那个决定实际超时。前端如果设了 15 秒，而 Nginx 设了 90 秒，那前端先断，后台还在发，日志就会显示连接被重置。
线程池打满导致整个服务不可用：流式请求长时间占用 Tomcat 线程，普通接口也拿不到线程。按 3.3 节单独开线程池，并且给 AI 线程池设CallerRunsPolicy或者直接拒绝，别让它拖垮主线程池。
排查顺序建议：先 curl 确认通道，再看 Spring 日志确认请求发出去了，最后看前端和网关的超时。从外到内，别一上来就改代码。
6. 长期编码与 Agent 场景的通道选择
如果你只是偶尔调一下模型做验证，用按量的 API Key 就够了。但如果你的老项目改造后要长期跑智能客服、代码辅助或者 Agent 类的任务，调用量会持续上来，这时候通道的稳定性和成本结构就值得单独考虑。
TaoToken 的 Coding Plan 适合长期编码和 Agent 场景，入口在 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。它的定位是给持续调用的场景提供一个稳定的通道，不用每次请求都去关心额度波动。对于已经改造完、准备上生产的项目，可以先把测试流量切过去跑一段时间，观察成功率和延迟，再决定要不要全量。
回到技术本身，老项目接 Spring AI 这件事，难点从来不在「调 API」这个动作，而在存量系统的兼容性和流式链路的稳定性。依赖地狱靠 BOM 对齐和排除传递依赖解决，流式超时靠三层超时对齐和线程池隔离解决。这两块理顺了，剩下的 Prompt 工程和监控都是增量工作。
最后给一个实用建议：改造过程中保留一个「最小可复现」的测试接口，就是第 4.3 节那个ping和stream。每次改完依赖或超时配置，先跑这两个接口确认没退化，再去跑完整的业务流程。这样出问题时能快速定位是配置改坏了还是业务代码的问题。
