纯前端直连大模型API：五分钟实现带流式输出的AI对话Demo-北京尧图网络

刚入门前端 AI 开发或者正想在个人项目里快速跑通一个“智能聊天框”玩法的人应该都体会过那种看了无数大模型科普文、API 文档读了一堆却迟迟没法在自己的页面里真正“说起话”的挫败感。这次分享一个我实际打磨过的快速起步方案五分钟构建一个前端 AI 对话 Demo。这个 Demo 不依赖复杂的后端服务不需要自己搭建向量数据库也用不上微调模型这套重型武器。它要做的事情很简单用纯前端页面直连云端的大模型接口实现一个带上下文记忆的聊天机器人界面。由于是基于浏览器的流式响应对话体验非常接近成熟的商业 AI 产品。这套方案非常适合做三件事检验大模型 API 在自己业务场景下的效果、作为课程设计或个人作品集的技术验证模块、以及给团队内部做一次 AI 能力的前端预演。无论你是刚摸过 HTML 的前端新手还是需要快速给产品“加点 AI”的开发者跟着这个实操流程都能在几分钟内跑通第一版可交互的对话界面。1. 整体设计思路与方案选型1.1 为什么选择“纯前端直连”而不是“后端代理”很多人第一反应是搭个后端服务再做中转觉得这样更“正规”。但在这个 Demo 阶段纯前端直连其实是更符合目标的选择。原因很实在。第一它砍掉了整条链路里最容易出问题的部分。一旦引入后端就要考虑接口鉴权、跨域处理、服务部署、日志监控一套流程这些工作本身就会消耗大量时间。第二AI 领域的关键接口大多是标准化的 RESTful 风格浏览器原生 fetch 就能直接调用根本不需要复杂的 SDK 封装。第三前端直连能最大限度地缩短“改动代码”到“看到效果”的反馈周期这对验证想法、调整提示词、演示交互效果来说极其重要。当然我这么说不是全盘否定后端方案。如果你的项目已经有多用户体系、需要保护业务数据、要隐藏接口密钥或者有复杂的权限控制那就必须走后端代理。这正好也呼应了我在第三节和第四节会专门讲的安全边界问题——纯前端方案的密钥暴露风险是真实存在的。1.2 技术栈与核心依赖选型技术选型上我遵循一个原则能少用一个依赖就少用一个依赖。这个 Demo 的标准栈就三样原生 HTML / CSS / JavaScript不需要构建工具不需要脚手架任何一个文本编辑器加浏览器就能跑。官方 REST API直接用模型服务商提供的 HTTP 接口不需要安装第三方 SDK。浏览器环境现代浏览器自带的fetch、ReadableStream都已足够实现对话和流式读取。为什么不推荐在起步阶段引入 React/Vue不是说它们不好而是框架的组件化、状态管理、虚拟 DOM 这些能力对“把一条消息发出去再渲染回来”这个核心场景来说属于过度设计。用原生 JS 写完第一版跑通了逻辑之后哪怕要迁移到 React也只是把消息数组的状态管理换掉而已成本很低。1.3 消息上下文机制的通俗解释对话系统的核心不只是“把这句话发给 AI”而是要让 AI “记得”你们之前聊过什么。大模型本身是“无记忆”的它的推理只基于你当前给它的输入。所以所有对话系统本质上都靠一个消息数组来模拟记忆。这里的关键在于消息结构。它一般长这样const messages [ { role: system, content: 你是一个智能助手。 }, { role: user, content: 你好介绍一下自己。 }, { role: assistant, content: 你好我是你的智能助手。 }, ]system消息用来设定 AI 的人设和行为准则user是用户输入assistant是模型之前的回复。每次发新消息时前端把整个数组原封不动发给接口大模型看到前面的对话记录就能顺着语境往下接。这就是最朴素的上下文实现方式。2. 核心细节解析与接口参数精讲2.1 API 密钥的管理与安全边界密钥是整个 Demo 里最需要你保持清醒的地方。在纯前端方案里密钥是直接写在代码里、运行在用户浏览器里的。这意味着任何人打开浏览器的开发者工具都能看到你的密钥。所以你必须明白这个 Demo 的密钥只配用于个人学习、内部演示、短期验证这类场景它的生命周期越短越好。我实操中的几个铁律分享给你申请密钥时一定选择“仅用于测试”之类的受限权限不开通计费之外的高额配额。用完即弃验证完功能马上在服务商控制台里把密钥删掉或重置。绝不在公开仓库、博客代码块里贴出完整密钥。在代码组织上建议把密钥集中放在一个单独的配置文件里方便统一修改。下面代码中出现的YOUR_API_KEY就是一个占位符你自己使用时替换成自己的密钥。注意如果后续要正式上线服务前端直连方案必须淘汰核心原因就是密钥无法在前端保密。这也是我反复强调的边界意识。2.2 tokens 计价机制与成本估算搞懂 tokens 的计价逻辑能帮你避免“聊着聊着没钱了”的尴尬。所谓 token可以粗略理解为模型处理文本的最小单元一个汉字大约占 1 到 2 个 token一个英文单词通常占 1 个 token。模型服务商按输入的 tokens 加上输出的 tokens 总和来收费。这里有一个很多新手会忽略的点历史消息累积的 tokens。你每发一条新消息要把之前的完整对话都带上对话轮数越多输入 tokens 越长。比如你连续聊了 20 轮最后一轮请求的输入里可能就有几千甚至上万个 token这一条请求的费用可能抵得上前面 19 轮请求的总和。所以我在 Demo 里加了一个非常实用的保护机制——滑动窗口截断。代码思路是这样每次发送前检查消息数组总长度超出阈值就把最前面的旧消息裁剪掉只保留最近的几条消息。实现如下const MAX_CONTEXT_MESSAGES 10; function trimMessages(messages) { if (messages.length MAX_CONTEXT_MESSAGES) { // 保留系统消息最近 MAX_CONTEXT_MESSAGES 条对话 const systemMsg messages.filter(msg msg.role system); const recentMsgs messages.slice(messages.length - MAX_CONTEXT_MESSAGES); return [...systemMsg, ...recentMsgs]; } return messages; }这样就能保证快速增长的历史记录不会让单次请求的成本失去控制同时也保护了接口的响应速度。2.3 核心请求参数的温度与最大长度请求参数里有几个关键项直接影响输出质量。首先是temperature中文常叫“温度”它控制模型输出的随机性。数值范围一般是 0 到 20 表示几乎总是选概率最高的结果输出稳定克制2 表示放飞自我各种可能性都能蹦出来。做客服问答、知识检索类场景我建议 0.3 左右做头脑风暴、创意文案1.0 上下比较合适如果做代码生成想兼顾准确和灵活0.6 左右是折中点。其次是max_tokens不同服务商叫法略有不同有的叫max_tokens有的叫max_completion_tokens。它限制的是单次回复最多生成的 token 数。设置太小会截断回答设置太大又容易在异常情况下产生额外费用。对 Demo 来说256 到 512 之间比较合理——既能覆盖绝大多数日常问答又不至于失控。然后还有一个容易忽略的stream参数。设置成true后接口不会一次性返回完整结果而是像打字机一样把内容一段一段推过来。这个参数对用户体验的影响是决定性的后面我会专门演示。3. 实操过程与核心功能实现3.1 第一步搭建页面骨架先创建一个index.html文件这个文件承载了聊天界面的所有结构。我刻意保持了极简的 CSS 风格让你能一眼看懂布局的层次关系。!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 titleAI 对话 Demo/title style * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, sans-serif; background: #f0f2f5; height: 100vh; display: flex; align-items: center; justify-content: center; } .chat-container { width: 480px; height: 640px; background: #ffffff; border-radius: 16px; box-shadow: 0 8px 32px rgba(0,0,0,0.12); display: flex; flex-direction: column; overflow: hidden; } .chat-header { background: #4f6ef7; color: #fff; padding: 16px 20px; font-size: 18px; font-weight: 600; } #chatBox { flex: 1; overflow-y: auto; padding: 16px; background: #fafafa; } .message { margin-bottom: 12px; display: flex; } .message.user { justify-content: flex-end; } .bubble { max-width: 75%; padding: 10px 14px; border-radius: 12px; font-size: 14px; line-height: 1.6; white-space: pre-wrap; word-break: break-word; } .user .bubble { background: #4f6ef7; color: #fff; border-top-right-radius: 4px; } .assistant .bubble { background: #e9edf5; color: #222; border-top-left-radius: 4px; } .input-area { display: flex; gap: 8px; padding: 12px; border-top: 1px solid #e5e7eb; background: #fff; } #userInput { flex: 1; padding: 10px 14px; border: 1px solid #d1d5db; border-radius: 8px; font-size: 14px; outline: none; } #userInput:focus { border-color: #4f6ef7; } #sendBtn { padding: 10px 20px; background: #4f6ef7; color: #fff; border: none; border-radius: 8px; cursor: pointer; font-size: 14px; } #sendBtn:disabled { background: #a5b0d8; cursor: not-allowed; } /style /head body div classchat-container div classchat-headerAI 对话 Demo/div div idchatBox/div div classinput-area input typetext iduserInput placeholder输入你的问题回车发送... button idsendBtn发送/button /div /div script srcapp.js/script /body /html这个布局的核心在于 flexbox 的纵向排列——头部固定、中间消息区自动撑开并滚动、底部输入区始终贴在底部。这种结构是聊天类界面的通用范式理解一次以后做任何聊天 UI 都是这个套路。3.2 第二步消息渲染与交互控制接着创建app.js第一步先实现消息数组的维护、渲染和输入控制。这里有几个细节我觉得值得拿出来讲。消息渲染我采用了最原始也最清晰的 DOM 创建方式不搞模板字符串拼接。原因很简单模板拼接容易引发 XSS 注入而 DOM 方式通过textContent设置文本天然转义了所有 HTML 标签更安全。const chatBox document.getElementById(chatBox); const userInput document.getElementById(userInput); const sendBtn document.getElementById(sendBtn); // 消息上下文数组第一条 message 固定是 system 人设 const messages [ { role: system, content: 你是一个聪明、友善的 AI 助手。请用简洁通俗的语言回答用户的问题。 } ]; let isWaiting false; function appendMessage(role, content) { const wrapper document.createElement(div); wrapper.className message ${role}; const bubble document.createElement(div); bubble.className bubble; bubble.textContent content; wrapper.appendChild(bubble); chatBox.appendChild(wrapper); chatBox.scrollTop chatBox.scrollHeight; return bubble; } function setWaitingState(waiting) { isWaiting waiting; sendBtn.disabled waiting; userInput.disabled waiting; if (waiting) { userInput.placeholder AI 正在回复中...; } else { userInput.placeholder 输入你的问题回车发送...; userInput.focus(); } }这里我把“等待响应”的状态单独抽成了一个函数好处是避免了用户在一个请求未完成时又连点发送导致消息顺序错乱。3.3 第三步核心请求逻辑与流式输出接下来是重头戏——调用接口并实现流式打字机效果。这里用fetch配合ReadableStream来处理流式响应。流式响应返回的格式一般是 SSE 风格每一行以data:开头最后一行是data: [DONE]。async function sendMessage() { const text userInput.value.trim(); if (!text || isWaiting) return; // 1. 把用户消息加入上下文并渲染 messages.push({ role: user, content: text }); appendMessage(user, text); userInput.value ; setWaitingState(true); // 2. 添加一个空的 assistant 气泡准备流式填充 const assistantBubble appendMessage(assistant, ); // 3. 裁剪历史消息控制 token 长度 const trimmedMsgs trimMessages(messages); try { const response await fetch(https://your-api-endpoint/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${YOUR_API_KEY} }, body: JSON.stringify({ model: your-model-name, messages: trimmedMsgs, temperature: 0.7, max_tokens: 512, stream: true }) }); if (!response.ok) { throw new Error(HTTP ${response.status}: ${await response.text()}); } // 4. 读取流式响应 const reader response.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; let fullContent ; 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 dataStr trimmed.substring(5).trim(); if (dataStr [DONE]) continue; try { const json JSON.parse(dataStr); const delta json.choices[0].delta?.content || ; if (delta) { fullContent delta; assistantBubble.textContent fullContent; chatBox.scrollTop chatBox.scrollHeight; } } catch (e) { console.warn(JSON 解析失败忽略该片段:, dataStr); } } } // 5. 把完整的 AI 回复存入上下文 messages.push({ role: assistant, content: fullContent }); } catch (err) { console.error(请求出错:, err); assistantBubble.textContent 请求失败${err.message}; } finally { setWaitingState(false); } } sendBtn.addEventListener(click, sendMessage); userInput.addEventListener(keydown, (e) { if (e.key Enter !e.shiftKey) { e.preventDefault(); sendMessage(); } });流式输出的实现有两个容易踩坑的细节。第一是缓冲区处理。网络传输中数据是分片到达的一个关键节点可能被切割成两半。上面代码里使用buffer暂存未处理完的文本每次按\n切分把最后一行留到下一次循环再处理。不这样做偶发的分片边界问题就会导致 JSON 解析失败。第二是TextDecoder的{ stream: true }参数。这个参数告诉解码器当前输入可能只是完整字节流的一部分请保留内部状态以正确拼接多字节字符。不加这个参数遇到中文字符被分到两个数据块里时就会出现乱码。3.4 第四步本地运行与效果验证代码写完后打开终端在项目目录下运行一个本地静态服务器。可以直接用 Python 自带的模块也可以用一个开源的静态服务器。只要浏览器能访问到index.html即可推荐 Python 方式python3 -m http.server 8000然后在浏览器打开http://localhost:8000输入一句“你好”如果一切正常你会看到 AI 的回复像打字机一样逐字输出。到这一步你的第一个前端 AI 对话 Demo 就已经跑通了。如果你遇到的不是这种效果比如点击发送后没反应或者直接报错直接调到下一节对照常见问题清单去排查命中率会非常高。4. 常见问题与排查技巧实录4.1 跨域 CORS 报错很多第一次做前端直连的人都会遇到这个报错Access to fetch at ... from origin http://localhost:8000 has been blocked by CORS policy。这个问题的原理是浏览器同源策略在保护用户一个网页只能请求同源的资源跨源请求必须由服务端在响应头里明确声明允许。好消息是主流的模型服务商的 API 都支持跨域调用专门就是为了方便云端和浏览器直连场景。排查步骤非常直接确认请求地址确实是服务商官方文档里给的完整路径不要多了或少了一级。检查请求头只有Content-Type和Authorization这两个自定义头没有额外添加像X-User-Id这种自定义头——新增自定义头会触发预检请求预检不过就直接失败。在浏览器的网络面板里看失败请求的响应信息如果响应头里有access-control-allow-origin就说明服务端没问题。重要一些公共代理接口或老旧的网关接口不支持 CORS这种情况无解只能换方案走后端代理。4.2 401 鉴权失败收到 401 错误码的排查优先级非常明确先看密钥再看请求地址然后看鉴权头格式。密钥最常见的问题是复制时带上了空格或者把控制台里的说明文字当成密钥的一部分给复制了进去。我建议在代码里打印一下密钥长度和官方控制台显示的密钥长度比对一下一眼就能看出有没有截断或多余字符。鉴权头格式方面绝大多数服务商要求Authorization: Bearer API_KEY。注意Bearer和密钥之间必须有一个空格分号、逗号、换行都会导致解析失败。部分服务商也支持api-key这类自定义请求头以官方文档为准。4.3 请求成功但没有 “打字机” 效果代码跑通后最常见的“不完美”表现是请求成功返回了但页面等了很久才一次性显示全部内容而不是逐字输出。这几乎都是stream参数没生效。排查时先确认请求体里的stream是布尔值true不是字符串true。然后用浏览器的网络面板查看响应内容如果响应体是一个完整的 JSON而不是一行行data:开头的 SSE那说明接口根本没进流式模式。还有一个小概率部分网关或本地代理工具会在中间缓冲响应体也造成流式失效。直接用浏览器访问请求地址排除中间环节就能定位问题。4.4 回复内容被截断或乱码“截断”和“乱码”是两个完全不同的原因。截断最常见的原因是max_tokens设置得比预期回复的长度小。你把设置调大比如 1024再做一轮测试如果没截断了就是这个参数的原因。另一个容易忽略的原因是流式读取时判断终止条件出错如果手动把[DONE]当作数据去解析也会出现异常中断。乱码几乎只和编码解码相关。确认响应解析部分使用的是TextDecoder(utf-8)并且decode的第二个参数传了{ stream: true }。最稳妥的验证方法是用浏览器的开发者工具抓取响应看数据本身是不是正常的中文 JSON如果是正常的问题就出在你的解析代码上。这个排查实录是我把实际踩过的坑整理出来的高频清单按顺序逐条对照大多数问题五分钟内都能定位。5. 从 Demo 到产品的扩展路径5.1 接入 Markdown 渲染与代码高亮Demo 跑通之后第一个值得做的升级是渲染。当前 AI 回复的文本是纯文本输出但大模型天生就爱生成 Markdown。如果你直接把它显示在页面上用户会看到满屏的**加粗**语法和成片的代码块标记非常影响观感。这时就需要引入一个 Markdown 渲染库前端生态里的成熟方案有很多成熟的轮子。引入之后把流式输出的完整内容先缓存起来每完成一轮对话后再一次性渲染成格式化 HTML。需要注意的细节是渲染时要处理 XSS 风险建议关闭原始 HTML 透传或者使用专门的 sanitize 库清洗用户内容。顺手把代码高亮也配上聊到程序问题时的观感会立刻从“玩具”变成“工具”。5.2 处理多轮对话的记忆与扩展标记上下文记忆目前靠的是无限增长的 messages 数组。真实产品不能这么做原因有二一是 token 成本线性上涨二是模型能接受的上下文窗口有上限超出后早期记忆会被直接排除。更成熟的方案是引入摘要记忆。当前简单粗暴的解决办法是维持滑动窗口但只在 Demo 阶段够用。升级到产品阶段至少要加一版“摘要压缩”当对话超过 N 轮后调用模型把之前的对话内容压缩成一个几百字的摘要用这个摘要替代原来的历史消息。这个方法实现简单效果却非常明显能让超长对话的 token 消耗和上下文丢失问题都得到缓解。如果想支持更丰富的信息形态比如让 AI 生成图表、思维导图可以研究一下“函数调用”的能力。它允许你在请求参数里声明一组可执行函数的签名模型在回答过程中如果觉得需要函数帮忙就会在响应里返回一个调用意图。前端收到后执行函数、把结果再传回模型模型基于结果继续生成最终答案。比如可以让 AI 调用前端定义好的“搜索新闻”函数拿到结果后再组织语言回答这就把静态大模型变成了能连接外部世界的智能体。5.3 接入 WebSocket 实现对话状态同步目前的架构里每个浏览器页面各自维护一份消息记录刷新页面后记录就没了。如果要做到“换设备接着聊”或者让多端信息互通就必须引入后端服务。一个清晰的做法是由后端统一维护会话消息浏览器页面通过 WebSocket 连接后端每次发送消息时后端代替前端去调用大模型收到模型流式输出后实时推送给所有连接到该会话的客户端。这样做还顺带解决了密钥安全的问题——密钥永远留在服务器端用户端只拿到聊天内容。5.4 补充产品化的拾遗最后还有三件“越小越容易被漏掉、但没有就一定显得业余”的事。第一给输入框加上发送频率限制防止用户连续点击造成重复请求和多笔扣费。第二把错误提示从技术细节翻译成用户能看懂的语言比如登录失效提示而不是直接甩一段英文栈文本。第三加一个“重新生成”按钮让用户可以在同一轮对话里重新请求一次 AI 回复这个功能在真实产品里被点击的概率远比你想象的高。实操总结几件我一直绷着的弦在你们动手之前我再把这几件我在实操中一直绷着的弦分享出来。第一密钥管理永不过度谨慎测试密钥用完就删这是最低成本的防呆机制。第二流式响应已经成了对话产品的标配能力你第一批代码里就处理好解码和缓冲逻辑后面迁移到任何框架都不会走老弯路。第三上下文管理和 token 控制要从第一版就放在心上不要等账单出来才想起“哦原来历史消息也要算钱”。第四遇到任何接口报错先打开浏览器的网络面板看请求和响应的完整数据大部分问题在这里都能直接找到答案比反复调代码高效得多。这几年我见过很多开发者被“要懂大模型原理才能做 AI 应用”这种话吓退实际动手做起来第一版最复杂的部分也就是一个fetch调用而已。这个 Demo 最好的结局是成为你产品里无数交互能力里那个最不起眼的基础设施而不是唯一的亮点。等你能熟练地在五分钟内把它搭起来你的注意力就能从“怎么调用”转移到“用它做什么”上——后者才是真正拉开差距的地方。

纯前端直连大模型API：五分钟实现带流式输出的AI对话Demo

相关推荐

STM32F407软件DDS函数发生器：定时器触发DAC与DMA实现波形生成

数字电路实验复习全攻略：从组合逻辑、时序逻辑到Verilog代码与实验报告闭环

C/C++程序注释删除实战：手写状态机实现词法分析

更多资讯

数据结构期末考什么？从一道综合题拆解复习重点与考场策略

GCC编译选项实战指南：从-O0到-O3的优化与调试

GCC编译选项实战指南：从调试到优化的高频选项详解

内核启动早期打印：从原理到实战的完整实现指南

Java开发者大模型应用转型指南：AutoGen与CrewAI多Agent实战

MFC集成ChartCtrl实现实时波形显示与性能优化

今日更新

悟空开源无代码平台实战：从实体建模到应用设计避坑指南

基于.NET9的多租户权限系统：数据权限与动态API落地实践

场地预约小程序毕设实战：SSM+微信小程序+MySQL数据库设计到避坑

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？