1. 从零搭一个网页聊天机器人卡点往往不在前端很多人第一次做网页版大语言模型聊天机器人HTML 和 CSS 半小时就写完了真正卡住的是接入层Key 放哪、请求怎么发、流式响应怎么接、多轮上下文怎么带、报错了怎么重试。我见过太多 Demo 把 API Key 硬编码在script里一提交就泄露也见过流式响应写了一半前端一直转圈不出字。这篇聚焦的就是这个接入层。我会用 TaoToken 作为统一的 Key/API 通道入口给你两份可直接复制的配置骨架——一份settings.json、一份config.toml再配一个能跑通的网页 Demo覆盖流式响应、多轮会话和错误重试。适合谁已经会写基础 HTML/JS、想把聊天机器人从能跑做到可复现联调的开发者。读完你能在本地完成一次端到端验证并用日志和状态码确认接入是否真的生效。先说清楚 TaoToken 在这里的角色它是一个统一的模型调用入口你拿一个 Key就能通过同一套 OpenAI 兼容协议去调不同的大语言模型不用为每个模型厂商单独维护一套鉴权和地址。对网页聊天机器人这种需要频繁切换模型做对比的场景省事很多。2. TaoToken 前置拿 Key、认地址、分清两种配置2.1 注册与获取 API Key进入官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台创建 API Key。这个 Key 就是后面所有请求的凭证格式通常是一串以固定前缀开头的字符串。拿到 Key 之后直接去 API Keys 管理页 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 复制别截图保存截图容易糊复制粘贴最稳。2.2 两个地址要分清这里有个容易踩的坑官网地址和 API 地址不是一回事。用途地址说明官网/控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册、充值、看用量API 基址https://taotoken.net/api代码里请求的 base_url不加 UTM代码里拼接的完整端点通常是https://taotoken.net/api/v1/chat/completions。注意/api后面跟/v1这是 OpenAI 兼容协议的标准路径。很多人把官网地址直接填进base_url结果 404就是这里搞混了。2.3 为什么用配置文件而不是硬编码把 Key 和模型名写死在 JS 里有三个问题一是泄露风险二是换模型要改代码三是没法区分开发/生产环境。用settings.json或config.toml把配置抽出来前端只读配置、不碰密钥明文是更稳的做法。注意纯前端网页直接请求 API 时Key 仍然会出现在浏览器网络面板里。生产环境务必加一层自己的后端代理把 Key 留在服务端。本文的配置骨架同时适用于前端直连做本地联调和后端代理读取配置两种模式。3. 可复制配置骨架settings.json 与 config.toml 双份3.1 settings.json前端/Node 通用这份配置适合前端 Demo 或 Node 脚本读取。字段设计上把连接信息和会话行为分开方便你只改一处。{ provider: { name: taotoken, base_url: https://taotoken.net/api/v1, api_key: sk-你的TaoToken密钥, timeout_ms: 60000 }, model: { name: gpt-4o-mini, temperature: 0.7, max_tokens: 2048, stream: true }, session: { max_history_rounds: 10, system_prompt: 你是一个简洁、准确的中文助手。 }, retry: { max_attempts: 3, base_delay_ms: 800, retry_on_status: [429, 500, 502, 503, 504] } }几个关键点解释一下。base_url结尾不要带/chat/completions只到/v1具体端点由代码拼。max_history_rounds控制带多少轮上下文带太多会撑爆 token 也会变慢。retry_on_status里 429 是限流、5xx 是服务端临时故障这两类才值得重试400 这种参数错误重试多少次都没用。3.2 config.toml后端/CLI 场景如果你用 Python 或 Go 写后端代理TOML 更清爽注释也友好。[provider] name taotoken base_url https://taotoken.net/api/v1 api_key sk-你的TaoToken密钥 timeout_ms 60000 [model] name gpt-4o-mini temperature 0.7 max_tokens 2048 stream true [session] max_history_rounds 10 system_prompt 你是一个简洁、准确的中文助手。 [retry] max_attempts 3 base_delay_ms 800 retry_on_status [429, 500, 502, 503, 504]两份配置字段一一对应你可以按技术栈选一份。Python 读取用tomllib3.11 内置或tomliNode 读取 JSON 直接JSON.parse即可。3.3 把配置接进网页 Demo下面这段是核心请求逻辑替换掉原来硬编码 Key 的写法。它做了三件事从配置读参数、带上下文发请求、按状态码决定是否重试。// 假设 settings 已通过 fetch 或内联方式加载 async function chatCompletion(messages, settings) { const { provider, model, retry } settings; const url ${provider.base_url}/chat/completions; const payload { model: model.name, messages, temperature: model.temperature, max_tokens: model.max_tokens, stream: model.stream }; for (let attempt 1; attempt retry.max_attempts; attempt) { try { const resp await fetch(url, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${provider.api_key} }, body: JSON.stringify(payload) }); if (resp.ok) return resp; if (retry.retry_on_status.includes(resp.status) attempt retry.max_attempts) { const delay retry.base_delay_ms * Math.pow(2, attempt - 1); console.warn(第 ${attempt} 次请求返回 ${resp.status}${delay}ms 后重试); await new Promise(r setTimeout(r, delay)); continue; } throw new Error(请求失败状态码 ${resp.status}); } catch (err) { if (attempt retry.max_attempts) throw err; const delay retry.base_delay_ms * Math.pow(2, attempt - 1); await new Promise(r setTimeout(r, delay)); } } }重试用了指数退避第 1 次失败等 800ms第 2 次等 1600ms第 3 次等 3200ms。这样既给了服务端恢复时间又不会把请求打爆。4. 流式响应与多轮会话把骨架跑起来4.1 流式响应怎么解析stream: true时服务端返回的是 SSEServer-Sent Events格式一行行data: {...}。浏览器里用ReadableStream逐块读遇到data: [DONE]就结束。async function streamChat(messages, settings, onDelta) { const resp await chatCompletion(messages, settings); const reader resp.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); // 最后一行可能不完整留到下一轮 for (const line of lines) { const trimmed line.trim(); if (!trimmed.startsWith(data:)) continue; const data trimmed.slice(5).trim(); if (data [DONE]) return; try { const json JSON.parse(data); const delta json.choices?.[0]?.delta?.content; if (delta) onDelta(delta); } catch (e) { // 忽略不完整分片 } } } }这里最容易出错的是buffer的处理。网络分片不会按行切一个 JSON 可能被切成两半所以必须把最后一行留到下一轮再拼。我试过直接split(\n)全处理结果偶发 JSON 解析失败就是没留 buffer。4.2 多轮会话的上下文管理conversationHistory数组要按 OpenAI 的messages格式存每条是{ role, content }role 取system/user/assistant。每次发请求前把 system prompt 放最前再截取最近 N 轮。function buildMessages(history, settings) { const { session } settings; const maxMsgs session.max_history_rounds * 2; // 一问一答算两条 const recent history.slice(-maxMsgs); return [ { role: system, content: session.system_prompt }, ...recent ]; }注意slice(-maxMsgs)是从尾部截取保证最近对话优先保留。system prompt 每次都要重新拼在最前面不能存进 history 里反复叠加否则会越滚越长。4.3 完整调用链把上面几块串起来一次发送的流程是用户输入 → push 进 history →buildMessages构造上下文 →streamChat流式拿回复 → 边收边渲染 → 收完把 assistant 回复 push 进 history。async function handleSend(userText) { appendMessage(user, userText); history.push({ role: user, content: userText }); const messages buildMessages(history, settings); let assistantText ; await streamChat(messages, settings, (delta) { assistantText delta; renderAssistantDelta(delta); // 增量渲染到气泡 }); history.push({ role: assistant, content: assistantText }); }5. 验证请求用日志和状态码确认接入生效5.1 先用 curl 打通链路在写前端之前先用 curl 确认 Key 和地址没问题能排除一大半环境问题。curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -d { model: gpt-4o-mini, messages: [{role: user, content: 用一句话介绍你自己}], stream: false }返回 200 且choices[0].message.content有内容说明接入层通了。如果返回 401是 Key 错了404 是地址拼错429 是限流等一会儿或降低频率。5.2 前端加日志观察状态码在chatCompletion里加一行状态码日志联调时非常有用console.log([TaoToken] status${resp.status} attempt${attempt});正常联调时你应该看到status200。如果看到status429后跟一次成功的 200说明重试逻辑生效了。如果连续三次都是 5xx那多半是服务端临时问题不是你的代码。5.3 验证流式是否真的流式判断流式有没有生效看两点一是回复是不是一个字一个字蹦出来而不是等半天一次性出现二是网络面板里响应类型是text/event-stream。如果是一次性出现检查stream参数是不是被配置覆盖成了false。5.4 验证多轮上下文发两句话测试第一句我叫小明第二句我叫什么。如果第二句能答出小明说明 history 正确带上了。如果答不出检查buildMessages有没有把 history 拼进去或者max_history_rounds是不是设成了 0。6. 本篇常见错排查6.1 401 Unauthorized最常见。原因通常是 Key 复制时带了空格、用了过期 Key、或者Authorization头拼错。检查格式必须是Bearer sk-xxxBearer和 Key 之间一个空格。另外确认你用的是 TaoToken 的 Key不是别家的。6.2 404 Not Found八成是base_url拼错。正确是https://taotoken.net/api/v1代码里再拼/chat/completions。如果你把官网地址https://taotoken.net/直接当 base_url就会 404。记住 API 地址是https://taotoken.net/api不带 UTM 参数。6.3 流式响应卡住不出字三个排查方向一是stream参数没传或传成 false二是buffer处理没留最后一行导致 JSON 解析一直失败三是没设Content-Type: application/json。另外有些环境对 SSE 有缓冲可以检查响应头有没有X-Accel-Buffering。6.4 上下文丢失或答非所问检查conversationHistory是不是每次请求都被清空了。常见错误是在sendMessage里重新声明了const history []导致每轮都是新数组。history 要定义在函数外层作为会话级状态。6.5 429 限流频繁触发降低请求频率或者把retry.base_delay_ms调大。如果并发高考虑在服务端做请求队列。重试逻辑本身没问题但别把max_attempts设太大3 次足够。6.6 模型名报错model.name必须是 TaoToken 支持的模型标识。如果你从别处抄了个模型名但平台不支持会返回 400 或 model not found。换模型时先在模型对话页确认可用模型列表。7. 下一步把接入层用起来配置骨架跑通之后接入层这块基本就稳了。接下来你可以做几件事。想快速验证不同模型在聊天场景下的表现直接去模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 试不用改代码就能对比回复质量选定模型再回填到settings.json。如果你要把这个聊天机器人往长期编码助手或 Agent 方向做比如接进 IDE、做自动化任务那按量计费的 API 调用可能不够划算可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 它更适合高频、长期的编码场景。接入过程中如果遇到鉴权、端点、参数这类问题接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里有完整的协议说明和示例比对着排查快很多。Key 的管理和轮换在 API Keys 页 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 操作建议开发和生产用不同的 Key方便单独吊销。最后提醒一句本地联调可以前端直连但上线前一定加后端代理把 Key 留在服务端。这一步不做前面所有配置做得再规范都白搭。 基于网页的大语言模型聊天机器人：用 TaoToken 统一 Key 接入的配置骨架与联调验证
1. 从零搭一个网页聊天机器人卡点往往不在前端很多人第一次做网页版大语言模型聊天机器人HTML 和 CSS 半小时就写完了真正卡住的是接入层Key 放哪、请求怎么发、流式响应怎么接、多轮上下文怎么带、报错了怎么重试。我见过太多 Demo 把 API Key 硬编码在script里一提交就泄露也见过流式响应写了一半前端一直转圈不出字。这篇聚焦的就是这个接入层。我会用 TaoToken 作为统一的 Key/API 通道入口给你两份可直接复制的配置骨架——一份settings.json、一份config.toml再配一个能跑通的网页 Demo覆盖流式响应、多轮会话和错误重试。适合谁已经会写基础 HTML/JS、想把聊天机器人从能跑做到可复现联调的开发者。读完你能在本地完成一次端到端验证并用日志和状态码确认接入是否真的生效。先说清楚 TaoToken 在这里的角色它是一个统一的模型调用入口你拿一个 Key就能通过同一套 OpenAI 兼容协议去调不同的大语言模型不用为每个模型厂商单独维护一套鉴权和地址。对网页聊天机器人这种需要频繁切换模型做对比的场景省事很多。2. TaoToken 前置拿 Key、认地址、分清两种配置2.1 注册与获取 API Key进入官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台创建 API Key。这个 Key 就是后面所有请求的凭证格式通常是一串以固定前缀开头的字符串。拿到 Key 之后直接去 API Keys 管理页 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 复制别截图保存截图容易糊复制粘贴最稳。2.2 两个地址要分清这里有个容易踩的坑官网地址和 API 地址不是一回事。用途地址说明官网/控制台https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册、充值、看用量API 基址https://taotoken.net/api代码里请求的 base_url不加 UTM代码里拼接的完整端点通常是https://taotoken.net/api/v1/chat/completions。注意/api后面跟/v1这是 OpenAI 兼容协议的标准路径。很多人把官网地址直接填进base_url结果 404就是这里搞混了。2.3 为什么用配置文件而不是硬编码把 Key 和模型名写死在 JS 里有三个问题一是泄露风险二是换模型要改代码三是没法区分开发/生产环境。用settings.json或config.toml把配置抽出来前端只读配置、不碰密钥明文是更稳的做法。注意纯前端网页直接请求 API 时Key 仍然会出现在浏览器网络面板里。生产环境务必加一层自己的后端代理把 Key 留在服务端。本文的配置骨架同时适用于前端直连做本地联调和后端代理读取配置两种模式。3. 可复制配置骨架settings.json 与 config.toml 双份3.1 settings.json前端/Node 通用这份配置适合前端 Demo 或 Node 脚本读取。字段设计上把连接信息和会话行为分开方便你只改一处。{ provider: { name: taotoken, base_url: https://taotoken.net/api/v1, api_key: sk-你的TaoToken密钥, timeout_ms: 60000 }, model: { name: gpt-4o-mini, temperature: 0.7, max_tokens: 2048, stream: true }, session: { max_history_rounds: 10, system_prompt: 你是一个简洁、准确的中文助手。 }, retry: { max_attempts: 3, base_delay_ms: 800, retry_on_status: [429, 500, 502, 503, 504] } }几个关键点解释一下。base_url结尾不要带/chat/completions只到/v1具体端点由代码拼。max_history_rounds控制带多少轮上下文带太多会撑爆 token 也会变慢。retry_on_status里 429 是限流、5xx 是服务端临时故障这两类才值得重试400 这种参数错误重试多少次都没用。3.2 config.toml后端/CLI 场景如果你用 Python 或 Go 写后端代理TOML 更清爽注释也友好。[provider] name taotoken base_url https://taotoken.net/api/v1 api_key sk-你的TaoToken密钥 timeout_ms 60000 [model] name gpt-4o-mini temperature 0.7 max_tokens 2048 stream true [session] max_history_rounds 10 system_prompt 你是一个简洁、准确的中文助手。 [retry] max_attempts 3 base_delay_ms 800 retry_on_status [429, 500, 502, 503, 504]两份配置字段一一对应你可以按技术栈选一份。Python 读取用tomllib3.11 内置或tomliNode 读取 JSON 直接JSON.parse即可。3.3 把配置接进网页 Demo下面这段是核心请求逻辑替换掉原来硬编码 Key 的写法。它做了三件事从配置读参数、带上下文发请求、按状态码决定是否重试。// 假设 settings 已通过 fetch 或内联方式加载 async function chatCompletion(messages, settings) { const { provider, model, retry } settings; const url ${provider.base_url}/chat/completions; const payload { model: model.name, messages, temperature: model.temperature, max_tokens: model.max_tokens, stream: model.stream }; for (let attempt 1; attempt retry.max_attempts; attempt) { try { const resp await fetch(url, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${provider.api_key} }, body: JSON.stringify(payload) }); if (resp.ok) return resp; if (retry.retry_on_status.includes(resp.status) attempt retry.max_attempts) { const delay retry.base_delay_ms * Math.pow(2, attempt - 1); console.warn(第 ${attempt} 次请求返回 ${resp.status}${delay}ms 后重试); await new Promise(r setTimeout(r, delay)); continue; } throw new Error(请求失败状态码 ${resp.status}); } catch (err) { if (attempt retry.max_attempts) throw err; const delay retry.base_delay_ms * Math.pow(2, attempt - 1); await new Promise(r setTimeout(r, delay)); } } }重试用了指数退避第 1 次失败等 800ms第 2 次等 1600ms第 3 次等 3200ms。这样既给了服务端恢复时间又不会把请求打爆。4. 流式响应与多轮会话把骨架跑起来4.1 流式响应怎么解析stream: true时服务端返回的是 SSEServer-Sent Events格式一行行data: {...}。浏览器里用ReadableStream逐块读遇到data: [DONE]就结束。async function streamChat(messages, settings, onDelta) { const resp await chatCompletion(messages, settings); const reader resp.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); // 最后一行可能不完整留到下一轮 for (const line of lines) { const trimmed line.trim(); if (!trimmed.startsWith(data:)) continue; const data trimmed.slice(5).trim(); if (data [DONE]) return; try { const json JSON.parse(data); const delta json.choices?.[0]?.delta?.content; if (delta) onDelta(delta); } catch (e) { // 忽略不完整分片 } } } }这里最容易出错的是buffer的处理。网络分片不会按行切一个 JSON 可能被切成两半所以必须把最后一行留到下一轮再拼。我试过直接split(\n)全处理结果偶发 JSON 解析失败就是没留 buffer。4.2 多轮会话的上下文管理conversationHistory数组要按 OpenAI 的messages格式存每条是{ role, content }role 取system/user/assistant。每次发请求前把 system prompt 放最前再截取最近 N 轮。function buildMessages(history, settings) { const { session } settings; const maxMsgs session.max_history_rounds * 2; // 一问一答算两条 const recent history.slice(-maxMsgs); return [ { role: system, content: session.system_prompt }, ...recent ]; }注意slice(-maxMsgs)是从尾部截取保证最近对话优先保留。system prompt 每次都要重新拼在最前面不能存进 history 里反复叠加否则会越滚越长。4.3 完整调用链把上面几块串起来一次发送的流程是用户输入 → push 进 history →buildMessages构造上下文 →streamChat流式拿回复 → 边收边渲染 → 收完把 assistant 回复 push 进 history。async function handleSend(userText) { appendMessage(user, userText); history.push({ role: user, content: userText }); const messages buildMessages(history, settings); let assistantText ; await streamChat(messages, settings, (delta) { assistantText delta; renderAssistantDelta(delta); // 增量渲染到气泡 }); history.push({ role: assistant, content: assistantText }); }5. 验证请求用日志和状态码确认接入生效5.1 先用 curl 打通链路在写前端之前先用 curl 确认 Key 和地址没问题能排除一大半环境问题。curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -d { model: gpt-4o-mini, messages: [{role: user, content: 用一句话介绍你自己}], stream: false }返回 200 且choices[0].message.content有内容说明接入层通了。如果返回 401是 Key 错了404 是地址拼错429 是限流等一会儿或降低频率。5.2 前端加日志观察状态码在chatCompletion里加一行状态码日志联调时非常有用console.log([TaoToken] status${resp.status} attempt${attempt});正常联调时你应该看到status200。如果看到status429后跟一次成功的 200说明重试逻辑生效了。如果连续三次都是 5xx那多半是服务端临时问题不是你的代码。5.3 验证流式是否真的流式判断流式有没有生效看两点一是回复是不是一个字一个字蹦出来而不是等半天一次性出现二是网络面板里响应类型是text/event-stream。如果是一次性出现检查stream参数是不是被配置覆盖成了false。5.4 验证多轮上下文发两句话测试第一句我叫小明第二句我叫什么。如果第二句能答出小明说明 history 正确带上了。如果答不出检查buildMessages有没有把 history 拼进去或者max_history_rounds是不是设成了 0。6. 本篇常见错排查6.1 401 Unauthorized最常见。原因通常是 Key 复制时带了空格、用了过期 Key、或者Authorization头拼错。检查格式必须是Bearer sk-xxxBearer和 Key 之间一个空格。另外确认你用的是 TaoToken 的 Key不是别家的。6.2 404 Not Found八成是base_url拼错。正确是https://taotoken.net/api/v1代码里再拼/chat/completions。如果你把官网地址https://taotoken.net/直接当 base_url就会 404。记住 API 地址是https://taotoken.net/api不带 UTM 参数。6.3 流式响应卡住不出字三个排查方向一是stream参数没传或传成 false二是buffer处理没留最后一行导致 JSON 解析一直失败三是没设Content-Type: application/json。另外有些环境对 SSE 有缓冲可以检查响应头有没有X-Accel-Buffering。6.4 上下文丢失或答非所问检查conversationHistory是不是每次请求都被清空了。常见错误是在sendMessage里重新声明了const history []导致每轮都是新数组。history 要定义在函数外层作为会话级状态。6.5 429 限流频繁触发降低请求频率或者把retry.base_delay_ms调大。如果并发高考虑在服务端做请求队列。重试逻辑本身没问题但别把max_attempts设太大3 次足够。6.6 模型名报错model.name必须是 TaoToken 支持的模型标识。如果你从别处抄了个模型名但平台不支持会返回 400 或 model not found。换模型时先在模型对话页确认可用模型列表。7. 下一步把接入层用起来配置骨架跑通之后接入层这块基本就稳了。接下来你可以做几件事。想快速验证不同模型在聊天场景下的表现直接去模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 试不用改代码就能对比回复质量选定模型再回填到settings.json。如果你要把这个聊天机器人往长期编码助手或 Agent 方向做比如接进 IDE、做自动化任务那按量计费的 API 调用可能不够划算可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 它更适合高频、长期的编码场景。接入过程中如果遇到鉴权、端点、参数这类问题接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里有完整的协议说明和示例比对着排查快很多。Key 的管理和轮换在 API Keys 页 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 操作建议开发和生产用不同的 Key方便单独吊销。最后提醒一句本地联调可以前端直连但上线前一定加后端代理把 Key 留在服务端。这一步不做前面所有配置做得再规范都白搭。