面试官：大模型流式输出前端怎么接的？候选人：EventSource——面试官：断线了怎么办？输出一半呢？#程序员 #前端 #AI #前端面试 #前端开发

面试官：你项目里AI对话的流式输出怎么实现呢？候选人：用的EventSource。面试官：网络断了正在输出怎么办？输出到一半的内容怎么处理？候选人：这个没想过。 今天刚面了一个三年前端，AI产品做了半年，问SSE流式渲染直接卡壳。说实话，现在做AI产品的前端，十个有九个只会用EventSource接数据，后面的问题一概没想过，真实翻车。 去年，一个AI写作产品，用户生成长文到一半网络抖动，SSE断联后，前端把已经收到的半截内容直接丢了，用户写了半小时的提示词白费，当天投诉量翻了三倍。更离谱的是，后端其实还在生成，只是前端丢了，白白浪费了一堆Token。 如果你对这个问题也不了解，我整理了让面试官沉默的大厂必考题库，涵盖MySQL灵魂拷问、Redis高频陷阱、Spring Boot十连问，点个赞，留个六六六，直接拿走。 一、SSE连接管理和断线重连： 1、原生EventSource只支持GET请求，大模型API基本都要POST加Header鉴权，所以实际项目大多用fetch的ReadableStream手动解析SSE。 2、断线重连不能靠原生自动重连，要自己监听error事件，判断是网络断开还是服务端主动关闭。 3、重连时要把已接收的Last-Event-ID带上，让服务端从断点续传，不是从头再生成一遍。 4、别忘了给连接设超时，AI生成长文可能要一两分钟，但连接建立本身不该超过十秒。 二、流式渲染的性能坑： 1、大模型每个chunk就几个字，直接每个chunk更新DOM，生成一篇两千字的文章，要触发几百次重渲染，页面直接卡死。 2、用requestAnimationFrame或定时器做节流，每五十到一百毫秒，批量合并内容再更新一次，用户视觉上没区别，但性能提升几倍。 3、长文本渲染，用虚拟列表或分段加载，别把几万字一次性塞进DOM。 4、盲渲染更要命，每个chunk都跑一次Markdown解析，计算量直接翻倍，攒一批再解析。 三、AI输出内容的安全问题： 1、大模型输出的Markdown里，可能带script标签和恶意链接，直接用v-html或dangerouslySetInnerHTML渲染就是XSS漏洞。 2、一定要用DOMPurify来做sanitize，或者用纯文本渲染器，而非直接插入Markdown。 3、AI生成的内容引用外部图片也可能有问题，图片链接可能失效，也可能追踪用户。 4、代码块里的内容也要转义，别让用户复制代码时中招。 四、中断和异常状态处理： 1、用户主动中断生成时，要用AbortController取消fetch请求，不是只停止渲染，请求还在跑，服务端还在算。 2、中断后已经收到的内容要保留，并标记为生成中断，别直接清掉，用户可能想基于半截内容继续。 3、服务端返回错误时的处理，区分是内容审核拒绝、Token超限还是服务暂时不可用，每种给用户不同的提示。 4、超时兜底必须有，设一个合理上限，比如六十秒，超时了主动断开，并提示用户重试。 避坑经验： 一、别用原生EventSource，fetch加ReadableStream才是生产级方案，支持POST和自定义Header。 二、渲染节流是必须的，不分chunk直接刷DOM，长文本生成时页面必卡。 三、AI输出必须做XSS防护，大模型生成恶意代码不是理论风险，是线上真出过事。 四、中断处理不能只管前端，AbortController取消请求、保留已有内容、状态标记三件套缺一不可。 做了这么多AI产品，前端能把SSE从连接到渲染到异常全链路说清楚的真不多。面试官问流式输出，你能把这四块串起来讲，直接拉开差距。你觉得SSE和WebSocket做AI流式输出哪个更合适？评论区说说你的理由。 抖音。