企业官网建设流程全解析

1. 为什么要在 Vue+Vite+TS 里统一 API 出口

前端项目做久了你会发现一个规律：接口地址散落在各个组件里，改一次域名要全局搜索替换，还容易漏。Vue+Vite+TS 这套组合本身对环境的支持很成熟，import.meta.env配合.env文件就能把 Base URL 抽出来，但很多人只做到「抽出来」，没做到「统一出口」。

我这次要解决的就是这个：把项目里所有请求的 Base URL 指向 TaoToken 的统一 API 通道，本地开发走.env.development，构建产物走.env.production，中间用 axios 封装层兜住，最后跑一次真实请求确认命中。

先说清楚 TaoToken 是什么、能做什么、适合谁。它是一个统一的大模型 API 接入通道，把不同模型的调用收敛到一套 Base URL 和 Key 上。对前端来说，你不需要为每个模型单独配地址，只要把请求出口指向https://taotoken.net/api，用统一的 Key 鉴权，就能在 Vue 项目里调模型对话、代码补全这类能力。适合谁？适合正在做 AI 功能的前端团队，尤其是用 Vue3 + Vite + TS 技术栈、希望请求层干净可控的开发者。

为什么强调「统一出口」？因为前端调模型和调普通业务接口不一样。模型接口的响应结构、超时时间、错误码都更特殊，如果每个组件自己fetch，拦截器、重试、鉴权全乱套。正确做法是：.env管地址，request.ts管实例，业务层只管调方法。

这一篇的路径是：先配.env，再写 axios 封装，然后跑验证，最后把常见报错过一遍。全程可复制，你跟着改就行。

2. TaoToken 前置准备：Key、Base URL 与模型 ID

在动前端代码之前，有三样东西要先拿到手，不然配置写了也跑不通。这三样就是 Base URL、API Key、Model ID，我习惯叫它们「三件套」。

Base URL 固定是https://taotoken.net/api，注意这里不带任何路径后缀，具体端点由请求时拼。API Key 需要你去控制台生成，入口在 API Keys 页面。生成后复制出来，它只会完整显示一次，丢了就得重新建。

Model ID 是你打算调用的模型标识，比如对话类、代码类各有对应的 ID。这个 ID 要和你实际请求的端点匹配，写错了会返回模型不存在的错误。

注意：Key 不要硬编码进.env.production然后提交到仓库。生产环境的 Key 应该走构建时注入或者后端代理，前端.env里放的应该是占位或通过 CI 变量替换。

拿到三件套后，建议先在命令行验证一次，确认 Key 本身可用，再去改前端。这样能把「Key 问题」和「前端配置问题」分开排查。验证方式很简单，用 curl 发一个最小请求：

curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 你的Key" \ -d '{ "model": "你的ModelID", "messages": [{"role": "user", "content": "ping"}] }'

如果返回里有choices字段，说明 Key 和模型 ID 都没问题，可以进入前端配置。如果返回 401，那是 Key 的问题；如果返回模型相关错误，那是 Model ID 的问题。这一步花两分钟，能省后面半小时。

另外提一句 Coding Plan。如果你这个 Vue 项目是要长期接模型做编码辅助或者 Agent 类功能，可以了解下 Coding Plan，它在调用额度和通道稳定性上更适合持续开发场景。短期验证用按量就行，长期跑再考虑。

3. 可复制配置：.env 变量与 axios 封装层

这一节是核心，所有片段都能直接抄。先建两个环境文件，放在项目根目录，和vite.config.ts同级。

.env.development：

VITE_MODE_ENV = "development" VITE_API_BASE_URL = "https://taotoken.net/api" VITE_API_KEY = "sk-你的开发Key" VITE_MODEL_ID = "你的ModelID"

.env.production：

VITE_MODE_ENV = "production" VITE_API_BASE_URL = "https://taotoken.net/api" VITE_API_KEY = "__INJECT_AT_BUILD__" VITE_MODEL_ID = "你的ModelID"

Vite 只暴露VITE_前缀的变量给客户端，这点要记住，写成API_KEY是读不到的。然后在src下建utils/request.ts，这是统一出口：

import axios, { AxiosInstance, AxiosRequestConfig } from 'axios' const baseURL = import.meta.env.VITE_API_BASE_URL const apiKey = import.meta.env.VITE_API_KEY const request: AxiosInstance = axios.create({ baseURL, timeout: 60000, headers: { 'Content-Type': 'application/json', }, }) request.interceptors.request.use( (config) => { if (apiKey && config.headers) { config.headers['Authorization'] = `Bearer ${apiKey}` } return config }, (error) => Promise.reject(error) ) request.interceptors.response.use( (response) => response.data, (error) => { if (error.response) { const { status } = error.response if (status === 401) { console.error('鉴权失败，检查 VITE_API_KEY') } } return Promise.reject(error) } ) export default request

注意超时我设了 60 秒，模型接口比普通接口慢，3 秒那种设置必超时。响应拦截器里直接返回response.data，业务层拿到的就是干净的数据。

再建一个src/api/chat.ts，把模型调用收口：

import request from '@/utils/request' export interface ChatMessage { role: 'user' | 'assistant' | 'system' content: string } export function chatCompletion(messages: ChatMessage[]) { return request.post('/v1/chat/completions', { model: import.meta.env.VITE_MODEL_ID, messages, }) }

这里baseURL是https://taotoken.net/api，post的路径是/v1/chat/completions，拼起来就是完整端点。这样业务组件只 importchatCompletion，完全不关心地址和 Key。

如果你用 Cline 或者 Claude Code 这类工具做辅助开发，它们的配置逻辑是一样的三件套。以 Cline 的 MCP 配置为例，Base URL 填https://taotoken.net/api，Key 填你的，Model ID 填对应模型。Codex 的auth.json也是同样三个字段。CC Switch 切换配置时，确保这三项一致，不然会出现「Key 对但模型不对」的隐性错误。

4. 验证请求：从本地 dev 到构建产物

配置写完必须验证，而且要分两种场景：本地开发服务器和构建后的产物。很多人只测了npm run dev，上线才发现.env.production没生效。

先看本地。在package.json里确认脚本带了 mode：

"scripts": { "dev": "vite --mode development", "build": "vue-tsc --noEmit && vite build --mode production", "preview": "vite preview" }

启动npm run dev，在任意组件里调一次：

import { chatCompletion } from '@/api/chat' async function testApi() { try { const res = await chatCompletion([ { role: 'user', content: '你好，返回一句话' } ]) console.log('命中成功：', res) } catch (e) { console.error('请求失败：', e) } }

打开浏览器 Network 面板，找到那条请求，确认三件事：Request URL 是https://taotoken.net/api/v1/chat/completions，Request Headers 里有Authorization: Bearer sk-...，Response 里有choices数组。三个都对，本地就算通了。

再看构建产物。执行npm run build，然后npm run preview。这里有个坑：preview默认不带 mode，读的是.env.production，但如果你 Key 写的是占位符，请求会 401。所以验证构建产物时，要么临时把真实 Key 填进.env.production本地测，要么用 CI 注入。

实测下来，构建产物验证最直接的方式是看打包后的 JS 里 Base URL 有没有被替换。在dist/assets里搜taotoken.net，能搜到说明环境变量注入成功。搜不到就是.env.production没被读取，检查文件名拼写和 mode 参数。

提示：Vite 的环境变量是在构建时静态替换的，不是运行时读取。所以改了.env必须重启 dev server 或重新 build，热更新不会生效。

两种场景都验证通过，说明你的统一出口是可靠的。这时候再去写业务功能，心里就有底了。

5. 常见报错排查：401、proxy failed 与 choices 读取失败

配置过程中最容易撞的几个错，我按真实报错信息列出来，对照着查。

401 Unauthorized。这个最常见，原因就三类：Key 没读到、Key 格式不对、Key 失效。先在浏览器控制台打console.log(import.meta.env.VITE_API_KEY)，如果是undefined，说明变量名没加VITE_前缀或者.env文件没放对位置。如果打出来是__INJECT_AT_BUILD__，说明你用的是生产占位符但没注入。如果 Key 正常还 401，去控制台确认 Key 是否被禁用。

local proxy failed / ECONNREFUSED。这个错通常出现在你还在用 Vite 的server.proxy转发旧接口。既然已经直连 TaoToken，就不需要代理了。检查vite.config.ts里有没有残留的proxy配置指向本地后端，有的话删掉或者改条件。另外确认baseURL是完整的https://开头，写成相对路径/api会走本地代理，自然失败。

Cannot read properties of undefined (reading 'choices')。这个错说明请求发出去了，但响应结构不对。两种可能：一是响应拦截器返回了response.data，但你的业务代码又取了一次.data，导致undefined.choices；二是接口返回的是错误对象，没有choices字段。先console.log完整响应，确认结构再取值。拦截器里返回response.data的话，业务层直接用res.choices。

OAuth / 鉴权头冲突。如果你项目里同时有登录态的Authorization和 TaoToken 的 Key，会互相覆盖。解决办法是给模型请求单独一个 axios 实例，或者用自定义 header 名区分。别在同一个实例上混用两套鉴权。

模型不存在 / model not found。检查VITE_MODEL_ID是否和端点匹配。对话端点和补全端点的模型 ID 可能不同，别混用。这个错和 Key 无关，纯粹是 ID 写错。

排查顺序建议：先看 Network 里的 Request URL 和 Headers，再看 Response body，最后看控制台报错。大部分问题在第一步就能定位。

6. 把请求出口固定下来，后续才好扩展

走到这里，你的 Vue+Vite+TS 项目已经有一套干净的请求出口了。.env管地址和 Key，request.ts管实例和拦截，api/chat.ts管业务方法，三层各司其职。以后要加新模型，只改 Model ID；要换通道，只改 Base URL；要加鉴权逻辑，只动拦截器。

如果你后面要接更多模型能力，或者做流式输出，建议在request.ts里加一个responseType: 'stream'的配置分支，别和普通 JSON 请求混在一起。流式响应的处理方式和普通响应差别很大，提前分开能少踩坑。

需要生成 Key 或者查接入细节，可以从 API Keys 页面进，接入文档在 doc 里。模型对话的在线验证入口在模型对话，长期做编码辅助的话 Coding Plan 更合适。这几个入口按你的场景选，别只停在首页。

最后留一个实用习惯：每次改完.env，先跑一次第 4 节的验证请求，确认命中再继续写业务。这个动作花不了一分钟，但能挡住 90% 的配置类问题。