1. 本地联调时AI Key 到底该放在哪一层做 SpringCloud Vue 后台管理项目的人大概率都遇到过这个场景后端拆成了 auth、gateway、system、business 好几个微服务前端 Vue 后台又要调 AI 能力做智能问答、内容生成或者数据摘要。结果 Key 一会儿写在application.yml里一会儿塞进前端.env改一次要重启三个服务前端还得重新 build。更麻烦的是不同微服务各自持有一份 Key谁调了多少、哪个服务超了额度完全对不上账。这个问题的本质不是Key 放哪而是多服务场景下凭证没有统一出口。SpringCloud 的微服务架构天然是分布式的每个服务独立部署、独立配置如果每个服务都直连模型厂商就会出现配置分散、额度割裂、轮换困难三个连锁问题。Vue 前端更尴尬——把 Key 打进前端产物等于公开泄露不放前端又得让后端代理代理层再写一遍 Key 配置等于把问题从一层搬到另一层。TaoToken 在这里扮演的角色是一个统一的 API 通道后端所有微服务、前端联调环境都指向同一个 base_url 和同一把 Key由它来统一转发到具体模型。这样配置只维护一份额度集中可见轮换时改一个地方就行。这篇就按SpringCloud 微服务 Vue 后台管理的真实联调流程把application.yml和.env的配置骨架给出来再走一遍前后端联调验证。适合谁看正在做或准备做 SpringCloud Vue 后台管理项目、需要给多个微服务接入 AI 能力、又不想把 Key 散落各处的开发者。下面所有配置都可以直接复制改。2. 前置准备TaoToken 的 Key 与通道地址在动application.yml之前先把两样东西拿到手一把 API Key一个统一的 base_url。Key 的获取入口在控制台的 API Keys 页面登录后新建一个即可建议按项目命名比如springcloud-admin-dev方便后面区分环境。地址是https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite通道地址统一用https://taotoken.net/api注意这个地址后面不加任何 UTM 参数直接作为 base_url 使用。它的作用和 SpringCloud 里的 gateway 很像——你不需要在每个微服务里配置不同厂商的 endpoint所有请求先到这一个入口由它按模型名路由。这里有个容易踩的点TaoToken 的 API 通道兼容 OpenAI 风格的接口协议也就是说后端用openai的 Java SDK 或者直接发 HTTP 请求都能对接不需要为它单独写一套客户端。对 SpringCloud 项目来说这意味着你可以在一个公共 module 里封装好调用逻辑其他微服务依赖这个 module 即可不用每个服务重复造轮子。拿 Key 和确认通道地址这两步做完就可以进入配置环节了。建议把 Key 先放到环境变量里不要直接硬编码进 yml后面会讲具体怎么引。3. 可复制配置application.yml 与 .env 骨架先看后端。SpringCloud 项目通常有一个common或者base模块把 AI 调用的配置集中放在这里其他微服务通过 Nacos 配置中心或者本地 yml 引入。下面是一个可以直接用的application.yml片段ai: taotoken: base-url: https://taotoken.net/api api-key: ${TAOTOKEN_API_KEY:} default-model: gpt-4o-mini timeout: 30000 max-retries: 2关键点是api-key用了${TAOTOKEN_API_KEY:}这种占位写法实际值从环境变量注入。本地开发时在 IDEA 的 Run Configuration 里加一个环境变量或者用.env文件配合启动脚本加载。这样 Key 不会进 Git团队协作时每人用自己的 Key互不干扰。如果你用 Nacos 做配置中心可以把base-url和default-model放在共享配置里api-key仍然走环境变量。这样多服务共享同一份通道配置改模型名只需要在 Nacos 改一次。再看前端 Vue 的.env文件。前端不直接持有 Key只配置后端代理地址# .env.development VUE_APP_BASE_API/dev-api VUE_APP_AI_PROXY_TARGEThttp://localhost:8080然后在vue.config.js里配代理把/dev-api转发到 gatewaymodule.exports { devServer: { proxy: { /dev-api: { target: process.env.VUE_APP_AI_PROXY_TARGET, changeOrigin: true, pathRewrite: { ^/dev-api: } } } } }这样前端调/dev-api/ai/chat实际打到 gateway 的/ai/chat由后端微服务去调 TaoToken。Key 始终留在后端前端产物里没有任何敏感信息。后端调用层建议封装一个TaoTokenClient用 Spring 的RestTemplate或者 WebClient 都行。核心是拼请求时把base-url和api-key带上Service public class TaoTokenClient { Value(${ai.taotoken.base-url}) private String baseUrl; Value(${ai.taotoken.api-key}) private String apiKey; public String chat(String prompt) { HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setBearerAuth(apiKey); MapString, Object body Map.of( model, gpt-4o-mini, messages, List.of(Map.of(role, user, content, prompt)) ); ResponseEntityString resp new RestTemplate().postForEntity( baseUrl /v1/chat/completions, new HttpEntity(body, headers), String.class ); return resp.getBody(); } }这段代码放在公共 module 里auth、system、business 哪个服务要用注入TaoTokenClient就行。gateway 层不需要特殊处理正常路由即可。4. 验证请求走一遍前后端联调配置写完得验证通道真的通。分两步先单独验后端再验前后端串联。后端验证最简单的方式是写一个测试接口或者直接用 curl 打 gateway。假设 gateway 跑在 8080system 服务注册在 Nacos 上路由规则是/system/**curl -X POST http://localhost:8080/system/ai/chat \ -H Content-Type: application/json \ -d {prompt:用一句话说明什么是微服务}如果返回里有正常的模型回复内容说明后端到 TaoToken 的链路是通的。这一步能过基本就排除了 Key 错误、base_url 写错、网络不通这几类问题。前端验证更贴近真实联调。启动 Vue 项目在后台管理页面里找一个能触发 AI 调用的按钮比如智能生成摘要。点击后打开浏览器 DevTools 的 Network 面板看请求是不是打到/dev-api/ai/chat状态码是不是 200响应体里有没有模型返回的内容。我试过在联调时遇到一种情况前端请求发出去了gateway 也收到了但返回 401。排查下来是api-key环境变量没注入成功${TAOTOKEN_API_KEY:}取到了空值。解决办法是在启动脚本里显式 export或者用 IDEA 的 EnvFile 插件加载.env。这类问题在 Network 面板里看响应体就能定位比翻日志快。验证通过后建议把这次请求的完整链路记一下Vue → devServer proxy → gateway → system 服务 → TaoTokenClient → TaoToken 通道 → 模型。哪一环出问题就在哪一环的日志里找线索。5. 本篇常见错排查联调过程中高频出现的错误就那么几类按现象对号入座即可。401 Unauthorized九成是 Key 没注入或者写错了。检查环境变量TAOTOKEN_API_KEY是否真的有值可以在启动类里打一行日志确认。另外注意Bearer前缀有没有漏setBearerAuth会自动加手写 header 的话别忘。404 Not Foundbase_url 拼错了。TaoToken 的通道地址是https://taotoken.net/api调用路径是/v1/chat/completions拼起来是https://taotoken.net/api/v1/chat/completions。如果多写或少写/v1就会 404。建议把完整 URL 打日志确认一次。前端请求跨域Vue 开发环境用 devServer proxy 一般不会有跨域问题但如果直接在前端代码里写死后端地址就会触发 CORS。正确做法是走/dev-api代理让 devServer 转发。生产环境则由 Nginx 做反向代理同样不暴露真实后端地址。Nacos 配置不生效如果base-url放在 Nacos 共享配置里改了之后服务没重新拉取可能是没加RefreshScope。在TaoTokenClient类上加这个注解配置变更后会自动刷新。超时模型响应慢的时候默认超时可能不够。timeout设成 30000 毫秒比较稳妥如果做流式输出还要单独处理 SSE 的超时。Key 额度问题如果返回 429 或者额度相关提示去控制台看一下用量。多服务共用一个 Key 时额度是共享的某个服务调用量大可能影响其他服务。这种情况可以考虑按服务拆 Key或者升级额度。排查顺序建议从外到内先 curl 验通道再验 gateway再验具体服务最后验前端。每层都通了问题自然就定位到了。6. 后续怎么用按场景选入口配置跑通之后日常使用会分几个方向。如果你主要是做模型能力验证、调 prompt、对比不同模型输出直接用模型对话页面最方便不用写代码https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite如果你在项目里要长期做编码辅助、接 Agent 或者做自动化任务Coding Plan 更适合它按编码场景做了优化https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite日常管理 Key、看用量、加额度还是在控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite接入文档里有完整的接口说明和示例遇到协议细节问题可以查https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你用 Claude Code 做开发Anthropic 兼容接入的说明在这里https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaude_code_anthropicutm_campaignrewrite回到项目本身这套配置骨架的价值在于Key 只维护一份前后端各司其职微服务之间通过公共 module 复用调用逻辑。后面加新服务、换模型、轮换 Key改动点都很集中。联调时按先通道后业务的顺序验证能省掉大量来回试错的时间。