企业官网建设流程全解析

你在浏览器里打开AI聊天界面，输入一句话，然后看到回复一个字一个字地蹦出来。这个体验如今已经成为AI产品的标配。但真正在前端实现过这个效果的同学都知道，背后的网络传输并不是什么黑魔法——绝大多数情况下，走的就是SSE（Server-Sent Events，服务器推送事件）。

我最初做AI对话项目时，也天真地以为直接发一个HTTP请求等完整响应回来就行。直到第一次写完，等了几秒屏幕还是一片空白，才意识到问题没那么简单。后来把方案换成SSE，效果完全变了：文本生成一点显示一点，首字延迟从秒级降到毫秒级，用户感知到的流畅度和之前完全不是一个量级。

如果你是前端开发，正在用或打算用AI能力做产品，这篇文章值得看完。我会从协议原理、技术选型、前端代码实操、踩坑经验四个维度，把SSE讲透。后端同学也能参考，涉及服务器端的部分我会尽量写得清楚。

1. AI逐字输出背后的真实机制：SSE到底是什么

1.1 传统请求-响应模型为什么不适合AI

先复盘一下我们最熟悉的HTTP请求流程：浏览器向服务器发一个请求，服务器开始计算结果，计算完成后把完整响应一次性返回，浏览器拿到全部数据后渲染页面。这就是经典的“请求-响应”模型，我们平时打开网页、调用API都是这套逻辑。

但AI对话的场景有一个根本差异：大模型生成一段回答需要几秒甚至几十秒，回答内容是一个token一个token产生的，而不是等所有token都生成完才一次性吐出来。如果沿用传统模型，用户发出问题后只能干等，少则三五秒，多则十几秒，屏幕上一个字都不出。大多数人等不了，体验就是“这AI是不是卡死了”。

而且从产品角度看，流式输出不仅仅是体验优化，它还承担了“反馈信号”的作用。用户看到文字一点点跳出来，就知道服务还在工作、正在处理自己的问题。这个即时反馈对信任感非常重要，所以几乎所有主流AI产品都会采用流式输出。

1.2 SSE的工作方式：一条长连接的“单项广播”

SSE解决这个问题的思路非常直接：客户端和服务器建立一条HTTP连接，连接保持不关闭，服务器在这条连接上按需持续推送数据给客户端。它的全称是Server-Sent Events，中文一般译作“服务器推送事件”，是HTML5标准的一部分。

这里的核心是“单向”二字。SSE只支持服务器向客户端推送数据，客户端不能通过同一条连接往服务器发数据。客户端要传达信息（比如输入框内容、用户指令），走的是普通的HTTP请求，两者互不干扰。

它的数据格式是基于文本的，服务器按约定好的格式一帧一帧地写数据，每一个完整事件之间用空行分隔。浏览器端只需要通过内置的EventSource API或者fetch的流式读取能力，就能实时收到这些数据并更新页面。由于格式简单、规范固定，SSE能够穿透几乎所有HTTP中间层，这在工程上是非常大的优势。

1.3 一个生活化的类比

理解SSE最直观的类比是“水管”。普通HTTP请求像你打电话问完事就挂断；WebSocket像是一通双向通话的电话，双方都能随时开口；而SSE更像一条单向输送的管道，服务器持续往管口里灌水，你只需要在另一头端着杯子接。你要给服务器递东西？那是另外一条管道的事。这个类比能帮你快速记住选型时的判断标准——你需不需要双工通信，决定你选SSE还是WebSocket。

2. SSE vs WebSocket：AI场景为什么选了SSE

2.1 为什么WebSocket不是AI流式输出的最优解

聊SSE时几乎绕不开WebSocket。很多人第一反应是：“要做实时推送，用WebSocket不就行了？”确实，WebSocket能做双向通信、能传二进制、能承载复杂自定义协议，功能上完全能实现流式输出。但放在AI对话场景里，用WebSocket属于功能过剩且自找麻烦。

每一个WebSocket连接都需要先通过HTTP发起握手（101 Switching Protocols），之后通信不再走HTTP协议栈。这意味着Nginx等反向代理、CDN、负载均衡器都得为WebSocket单独配置，连接超时、心跳检测、跨域认证这些原本HTTP层面的成熟机制也都要重造一遍。很多团队为了一个对话流式功能引入WebSocket，结果第二天就在生产环境遇到代理断开、连接不稳定、服务的并发连接数飙升等问题。

还有一个被很多人忽略的点：AI对话服务通常是无状态的，服务器不需要记住“这个客户端是谁”来推送数据。每次对话请求就是一次普通HTTP POST，服务器在响应体中把生成结果持续写出来就可以了。既然不需要服务端主动发起推送（对“服务器主动推送”这件事，SSE的语义反而更准确），WebSocket的双工能力就白白浪费了。

2.2 SSE恰好命中AI场景的所有约束

反过来看SSE，它天然契合AI场景的几个实际约束：

第一，AI服务大多通过HTTP REST接口暴露，SSE本身就是HTTP协议内容，不用额外协议升级，中间层兼容成本低。第二，前端可以最简单地用浏览器的EventSource来接收，几乎不用写解析代码。第三，断线重连是标准里内置的机制，网络闪断后浏览器会按约定自动重新连接，这一点对移动端弱网环境特别重要。第四，AI返回内容本质是纯文本，SSE的文本帧格式完全够用，甚至可以直接跟OpenAI、Anthropic这些大厂商的流式接口对齐。

2.3 什么情况下你才应该选WebSocket

讲清楚这一点，是为了避免你走到另一个极端。WebSocket仍然有它不可替代的场景：如果产品需要双向实时通信，比如在线协作编辑、多人画布、实时金融行情、直播弹幕的收发，那SSE就做不了，那些场景服务端需要实时接收客户端的指令并广播给其他客户端，必须用WebSocket。

简单说，选型时可以问自己三个问题：数据是我单向发给客户端的，还是客户端也要发给我？协议需要传输二进制数据吗？需要定制复杂消息结构吗？如果只是“服务器生成什么，前端就展示什么”，请优先选SSE。反过来说，如果你的场景里客户端消息频繁、消息量小、需要毫秒级双向延迟，那WebSocket更合适。

2.4 SSE和WebSocket关键参数对比

这个表格是我在实际项目里经常给团队贴的。多数时候把SSE这一列看明白就够用了。

3. 前端接入SSE的实操：从EventSource到fetch流式读取

3.1 用原生EventSource快速跑通最简单的demo

如果只做最简单的展示，只给一个GET接口，不需要传自定义请求头，那EventSource是成本最低的方案：

const chatTitle = document.getElementById('chat-title'); const eventSource = new EventSource('/api/chat/events'); // 监听默认的message事件 eventSource.onmessage = (event) => { const data = JSON.parse(event.data); chatTitle.textContent += data.token; }; // 监听错误 eventSource.onerror = (err) => { console.error('SSE连接异常', err); // 浏览器会自动尝试重连，这里只做提示 };

这是SSE最基础的形态。浏览器帮你完成连接建立、事件解析、断线自动重连，你只需要绑定回调函数就行。

但实际做AI产品时，EventSource往往不够用。原因有两个：

第一，EventSource只能用GET请求。而AI对话场景里，用户输入的prompt通常很长，历史消息也可能很大，GET没法带你自己的认证Token，也没有办法方便地传JSON body。第二，EventSource不能自定义请求头，这在需要携带Authorization鉴权时就很头疼，尤其是在前端不存Cookie而存Token的现代应用里。

3.2 fetch + ReadableStream：AI前端的主流做法

所以现在主流AI前端实现，走的基本都是“fetch + ReadableStream”这条路。原理是用fetch发起普通HTTP请求（可以是POST），但不在拿到完整响应后才读取，而是通过response.body.getReader()拿到底层的数据流，一帧一帧地边接收边解析。

说得直白一点：response.json()是等所有数据到齐后一次性解析，而reader.read()是数据到的每一块都让你有机会立刻处理。你完全可以控制读取节奏，想停止就不再调用read()。

一个典型实现如下：

async function chatWithAI(userInput) { const response = await fetch('/api/chat', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${token}`, }, body: JSON.stringify({ message: userInput }), }); if (!response.ok) { throw new Error(`HTTP ${response.status}`); } const reader = response.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 }); // SSE事件以空行分隔，按 '\n\n' 切分 const events = buffer.split('\n\n'); // 最后一段可能是不完整的，保留在buffer里 buffer = events.pop(); for (const rawEvent of events) { handleSSEChunk(rawEvent); } } } function handleSSEChunk(rawEvent) { // SSE行格式：data: {json}\n const lines = rawEvent.split('\n'); const dataLine = lines.find((line) => line.startsWith('data:')); if (!dataLine) return; const payload = dataLine.slice(5).trim(); if (payload === '[DONE]') return; try { const parsed = JSON.parse(payload); renderToken(parsed.token); } catch (e) { console.warn('解析失败，本次数据完整吗？', payload); } }

这里最关键的两个细节，也是我早期容易出错的地方：

第一，TextDecoder必须要传{ stream: true }。因为UTF-8的中文字符是多个字节的，网络分包可能把一个汉字拆在两块数据里。如果不用流式解码，你会在边界处看到乱码。用了之后，解码器会缓存不完整的字节，等下一个块来了再拼起来。

第二，数据要按\n\n切分，而不是只按行切分。SSE的协议里，一个事件可以有多行字段，事件之间是用一个空行分隔的。如果你逐行处理，遇到某些多行格式时会漏数据。还有，有些服务端为了兼容性会在data后带上空格，所以解析时要用slice加trim，把多余空格清掉。

3.3 完整可运行的demo：Node.js后端加前端页面

为了让你能直接跑起来，我提供一个很小的Node.js示例。后端用Express模拟一个AI流式接口，每间隔100毫秒推送一个字：

// server.js const express = require('express'); const app = express(); app.post('/api/chat', async (req, res) => { res.setHeader('Content-Type', 'text/event-stream'); res.setHeader('Cache-Control', 'no-cache'); res.setHeader('Connection', 'keep-alive'); const answer = '你好，我是通过SSE逐字输出的AI助手。'; const words = answer.split(''); for (const word of words) { // 一个完整SSE事件 res.write(`data: ${JSON.stringify({ token: word })}\n\n`); // 模拟生成延迟 await new Promise((resolve) => setTimeout(resolve, 100)); } res.write('data: [DONE]\n\n'); res.end(); }); app.listen(3000, () => { console.log('server on http://localhost:3000'); });

前端页面里只需要一个输入框和一个显示区域，配合前面一节提供的chatWithAI函数，就可以在浏览器里看到逐字输出的效果。这整个demo的原理跟业界大厂的AI流式接口是一致的：后端读取大模型输出，按token封装成data:行，通过响应流写出去；前端把流里的数据逐条解析、逐条渲染。

3.4 停止生成怎么实现：AbortController

流式输出还有一个交互需求很容易被忽略，就是“停止生成”。

用户在AI回复到一半时点了停止按钮，后端可能还在生成，前端必须主动断开连接。用fetch的AbortController可以很简单地实现：

let abortController = null; async function startChat() { if (abortController) { abortController.abort(); } abortController = new AbortController(); const response = await fetch('/api/chat', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ message: input.value }), signal: abortController.signal, }); // ... 后续读取逻辑不变 } function stopChat() { abortController?.abort(); }

调用abort()之后，reader.read()会立刻抛出一个AbortError，循环就会退出。你需要在读取循环里捕获这个异常，并清理UI状态。如果不做这一步，用户点击停止后，文字还会继续蹦出来，体验很差。

4. 实战排雷：断线重连、缓冲、连接数限制，这些坑我替你踩过了

4.1 EventSource的自动重连，和fetch方案的手动重连

EventSource有个非常省心的特性：连接断开后浏览器会自动重连，并且会带上Last-Event-ID头，让服务器知道从哪条事件继续推送。这个机制在直播流、数据看板场景很好用。

但换成fetch方案后，自动重连就没了。你需要自己判断何时重连、重连多少次、是否退避。我一般会封装一个带重试策略的流式请求工具，大致思路是：读取循环结束或异常退出后，如果不是用户主动中止，就启动一个指数退避的重连定时器，最多重试3次，每次间隔按1秒、2秒、4秒递增。同时把重连状态暴露给UI，让用户可以感知到“当前正在重连”。

这里有一个小建议：重连时尽量不要重复提交用户问题。AI对话场景里，服务端往往已经把整个prompt接收完才开始生成，重连时如果重新POST，相当于让大模型重新生成一遍，浪费token。更合理的做法是让后端支持按会话ID续推，但这个复杂度比较高。对于多数MVP产品，比较稳妥的方案是重连后提示用户“网络不稳定，请重新发送”，而不是自动重发。我见过不少团队为了让自动重连生效，结果用户看到重复回复的问题。

4.2 Nginx反向代理和CDN的缓冲陷阱

这是前端连调时最经典的一个坑：本地起服务跑得好好的，推到测试环境之后就发现SSE变成一堆数据一次性返回，或者连接一直不返回数据。十有八九是Nginx或其他反向代理开了缓冲。

Nginx默认proxy_buffering是开着，它会等上游服务器攒够一定字节才发给客户端。SSE本身是按事件流持续写的，每帧可能只有几十个字节，代理一缓冲，浏览器端就会一直等不到消息。解决办法有三层，从最推荐到最不推荐排列：

服务端显式返回X-Accel-Buffering: no响应头，告诉Nginx这个响应不要缓冲：

res.setHeader('X-Accel-Buffering', 'no');

如果服务端不好改，就在Nginx配置里针对这个路径关闭代理缓冲：

location /api/chat { proxy_buffering off; }

CDN层面也需要确认是否支持SSE透传，部分CDN默认也会缓冲HTTP响应。如果CDN不支持text/event-stream的透传，就让SSE请求走直连域名，避免被CDN缓存层干扰。

4.3 HTTP/1.1的6个并发连接限制

浏览器的HTTP/1.1同域名并发连接数限制一般是6个。SSE占用一个长连接，如果同一个页面里打开多个SSE流，比如同时打开3个AI对话窗口，就会占满3个连接。再加上页面本身有很多需要加载的资源请求，容易出现请求排队阻塞。

解决方案有几个方向：第一，把SSE接口放在独立域名或子域名下，避免和主站资源请求抢连接。第二，如果是AI产品里多个并发会话，可以考虑用一个SSE连接做多路复用，例如每个对话分配一个会话ID，通过同一条连接下发不同会话的消息，前端按ID分发渲染。第三，推进HTTP/2是根本解法，因为HTTP/2的并发连接在一个域名下只需一个TCP连接，不存在6条限制。

4.4 中文乱码与TextDecoder的事

前面提到TextDecoder的{ stream: true }参数，这里专门讲一下为什么。

网络传输的最小单位是字节流，一个UTF-8汉字通常占3个字节。服务器往响应里写数据时，浏览器收到的数据块大小并不按字符边界对齐。比如“你好”这个词可能会被拆成第一个数据块6个字节、第二个数据块0个字节，也可能会把第一个汉字的第三个字节放到了下一块。

TextDecoder如果不启用stream模式，每次解码遇到一个不完整字符就会返回一个替换字符（通常是�）。启用stream模式后，它会缓存不完整字节序列，等后续数据补齐后再输出完整字符。这个坑在纯英文内容里完全不存在，但一旦中文、日文等多字节字符进入，就会频繁踩到。

让我给一个对比示例：

// 错误写法：中文可能乱码 const chunk1 = decoder.decode(value1); // '你' const chunk2 = decoder.decode(value2); // '好' // 正确写法 const chunk1 = decoder.decode(value1, { stream: true }); const chunk2 = decoder.decode(value2, { stream: true });

流式模式还有个好处：它对性能几乎没有额外损耗，反而因为不需要为了凑完整字符而攒缓冲，内存管理更干净。

4.5 后台标签页的SSE行为

这里再说一个容易被忽略但真实存在的现象：浏览器对后台标签页的定时器和任务有限流，SSE事件可能也会被延迟处理。

Chrome后台标签页里的SSE连接通常会保持，但事件触发频率，尤其是涉及DOM更新和定时任务时，会被浏览器降级处理。比如你在后台开着AI对话，切到别的标签页几分钟，切回来可能发现所有内容一次性全部渲染出来了。这不是你的代码有bug，而是浏览器在帮你省资源。

如果你的场景对后台推送有强需求，比如“后台生成完要给用户一个通知”，不要指望SSE本身能唤醒或通知用户，应该配合Notification API、桌面通知等方式做兜底。SSE的职责是数据传输，不负责任务调度。

5. 深入SSE协议细节：event-stream格式与AI返回的对应关系

5.1 SSE的五个标准字段，搞懂就不虚了

SSE数据格式是纯文本，每一行以冒号分割字段名和值。常见的字段有五个：

data表示数据行，多行data会被拼接成一个事件的数据。event表示自定义事件类型，客户端可以监听不同类型的事件。id表示事件ID，浏览器重连时会带上Last-Event-ID。retry表示重连时间间隔（毫秒）。:开头的行是注释，常用于保活，防止代理断开空闲连接。

完整的SSE事件格式如下：

event: token id: 42 data: 你好

客户端在EventSource里监听自定义事件：

eventSource.addEventListener('token', (event) => { console.log(event.data); });

换成fetch方案后，这些字段都需要自己解析。实际使用中，event和id用得不算多，data是最核心的，retry偶尔会用到。AI流式接口的返回，说白了就是把每一次生成的token都塞进一个data字段里，用\n\n隔开。

5.2 OpenAI等大模型流式接口的返回格式

很多大模型服务商的流式接口，采用的实际上就是SSE格式。比如OpenAI的Completions流式响应，每帧长这样：

data: {"id":"chatcmpl-123","object":"chat.completion.chunk","choices":[{"delta":{"content":"你好"},"index":0}]} data: {"id":"chatcmpl-123","object":"chat.completion.chunk","choices":[{"delta":{"content":"，"},"index":0}]} data: [DONE]

这个格式里有两个需要前端注意的点：

每个data:后面的JSON是增量数据，不是完整回复。累加所有的content才能得到完整文本。data: [DONE]是流结束的标志，读到这个标记就该停止解析了。有些服务商使用其他结束标志，比如[DONE]变体，接入时要先确认文档。

不少前端同学第一次对接时，会试着把所有data块拼起来一次性JSON.parse，结果发现解析失败。原因很简单：大模型生成的每一帧都是一个独立的JSON对象，而[DONE]一帧不是合法JSON。正确做法是逐帧解析，遇到DONE结束标识就退出循环。

5.3 为什么有的AI应用返回格式不是标准SSE

还有一类常见情况是：你抓包发现AI应用的接口返回格式，并不是严格意义上的SSE。比如它用\n而不是\n\n分隔，或者没有data:前缀，直接丢一个JSON对象。

这里要分两种情况看。如果是自研后端，那只是“类似SSE”的长连接响应，没严格按标准格式写，你的前端解析逻辑就要自己适配。如果是对接大厂商，必须严格按对方的协议格式，不能想当然按标准SSE解析。

我给一个建议：对接任何流式接口，第一件事就是打开DevTools的Network面板，查看响应的原始内容，确认分隔符、字段前缀、结束标记这三个关键特征。不要凭着感觉写一个通用解析器。我在项目里见过多次因为“我以为返回的是标准SSE”导致的解析bug，其实后端只是用了Content-Type: text/plain的普通长连接，字段是自定义的。这种时候，按标准SSE解析反而会出错。

5.4 服务端实现SSE的几个关键设置

如果你还需要写后端，注意这几点：

响应头最少要有三个：Content-Type: text/event-stream、Cache-Control: no-cache、Connection: keep-alive。其中Connection: keep-alive是为了保证连接不被中间层关闭，有的环境还需要加上X-Accel-Buffering: no。部分服务端框架默认会压缩响应（gzip），SSE是流式文本，压缩后反而可能让浏览器端解析延迟，建议给SSE接口关闭压缩。还有一点，如果业务要识别用户连接断开，可以在循环写数据时检查res.writableEnded或者监听close事件，及时停止生成逻辑，避免白费token。

我见过很多刚接触SSE的后端同事，以为写res.write时把数据刷出去就够了，结果忘了设置Content-Type: text/event-stream，浏览器端EventSource直接报错。这个问题排查起来很隐蔽，因为接口用curl测试时数据是正常的，只有浏览器会严格校验MIME类型。

6. 一些值得留意的细节优化

6.1 节流合并渲染：SSE快起来也很猛

大模型生成速度偶尔会非常快，后端可能一次性推送多个token。如果前端每收到一个token就立刻document.getElementById().textContent += token，短时间内的大量DOM操作会让页面卡顿，尤其是在长对话场景。

我在项目里的优化思路是：把token先放进一个队列，然后用requestAnimationFrame批量渲染。每一帧最多渲染一批内容，保证UI流畅度。这个方法对打字机效果的平滑度提升非常明显，代码也简单。

6.2 安全与合规：不要让用户输入直接进DOM

当你把AI返回的内容渲染到页面时，务必小心XSS问题。AI输出的文本本质是用户可控的内容，如果直接在页面里用innerHTML插入，等于给用户开了一个注入窗口。低风险方案是用textContent渲染，这样在聊天界面里展示纯文本，特殊字符安全显示。如果需要支持富文本或Markdown，也要用成熟的markdown库并做sanitize，而不是自己写替换逻辑。

6.3 SSE连接的健康监测与心跳检测

生产环境里，SSE连接经常会被中间的网络设备静默断开。浏览器EventSource自带重连机制，但如果是自己写的fetch流，建议在业务层做心跳保活。

心跳检测的思路是：前端每隔一段时间（比如30秒）检查一次是否还有数据到达。如果超过某个阈值（比如60秒）没有任何事件，就判定连接可能已经挂了，主动断开并触发重连流程。这个方法尤其适合AI流式输出中间出现长停顿的场景，防止用户等待时连接早已失效。

7. 这篇读到这里，你可以直接动手做的东西

7.1 最小可用模板

总结一下，一个AI流式对话前端的最小实现包含四块：发起fetch流式请求、按\n\n分隔解析SSE事件、逐token更新UI、支持用户中断。把这四块封装成一个函数，后续对接任何AI服务商只需要更换解析逻辑。

我通常会把handleSSEChunk设计成一个可注入的回调函数，每个项目只改这一处，其他代码完全复用。

7.2 一个简短的检查清单

接入SSE时，对照检查：

服务端响应头是否包含Content-Type: text/event-stream。数据帧是否以空行（\n\n）结尾。结束标记是什么（[DONE]还是自定义）。前端解码是否使用TextDecoder的{ stream: true }。是否有缓冲层在中间捣乱。连接断开时是否有重连策略。用户中断是否调用了abort()。DOM更新是否做了节流。这些点全部确认过之后，流式输出基本就稳了。

8. 最后分享一个实操心得

如果让我给刚接触SSE的前端一个最实用的建议，那就是：先用EventSource跑通一个最简单的demo，把“连接、收消息、断线重连”这三件事的直觉建立起来，再去换成fetch流式读取。很多人在初始阶段直接上手fetch流式方案，被手动解析、手动重连、手动处理结束标识这些细节整得晕头转向，其实绕了远路。

我在实际项目中反复验证下来，EventSource适合快速原型验证和数据看板，而fetch流式读取适合深入业务场景的AI对话交互。大多数稳定上线的AI前端项目，最终都会落在fetch方案上，不是因为EventSource不好，而是因为认证、POST、自由度这些现实约束太多。

还有一个习惯值得养成：凡是接触流式接口，先把原始返回抓下来保存一份，无论是用DevTools还是用curl，都要看一遍原始响应长什么样。格式决定解析，解析决定体验。你能看到的原始数据帧越清晰，前端代码就会越稳。

SSE本身并不是多前沿的技术，HTTP长连接加文本事件流这套组合，很多年前就已经在标准里了。只是AI应用的大规模流式渲染需求，让它重新走到了前端主舞台。把这套机制理解透了，AI对话的流畅度、网络异常处理、协议兼容这些问题就都有了抓手。