1. 这不是“面试技巧”是AI时代前端工程师的生存切口“最后提醒一次9月的AI前端面试不用太老实”——这句话在技术社区刷屏时我正用TypeScript写一个SSE流式响应的错误重试逻辑。它不像“React Hooks原理”那种经典题能靠背题库硬刚也不像“手写Promise”那样有标准答案模板。它是一把钥匙打开的是当前前端岗位真实能力边界的那扇门你到底是在调API还是在和AI协同构建实时反馈闭环我带过6届校招面试今年明显感受到变化——问“Vue响应式原理”的人少了但问“你怎么让大模型输出的JSON不崩掉你的TS类型系统”的人多了考“防抖节流实现”的少了但现场让你用WebSocket接住一个持续30秒的AI推理流、并做分块渲染的多了。核心关键词已经非常清晰AI前端、TypeScript、流式处理、SSE、WebSocket。这五个词不是并列关系而是存在强依赖链AI服务端输出必须是流式的否则用户等30秒才看到第一行代码前端必须用SSE或WebSocket接收HTTP短连接扛不住长耗时AI响应而TypeScript是整个链路的“安全网”——没有它流式数据一来类型就崩UI就炸debug要靠console.log猜半天。所谓“不用太老实”根本不是教你糊弄面试官而是说别再只准备“我能写个TodoList”得准备好回答“当AI返回的代码块中间突然插了一段Markdown说明你的渲染组件怎么不报错还能高亮”这种问题。适合谁所有正在投递2024年Q3前端岗位的人尤其是用Vue/ReactTS栈、做过管理后台或低代码平台的开发者。你不需要自己训练大模型但必须清楚怎么把它“接进”你的工程体系里且接得稳、接得准、接得可维护。我见过太多候选人卡在同一个地方面试官说“假设后端用SSE推AI生成的代码片段每500ms一条你怎么在前端渲染”候选人立刻开始写useEffectfetch然后被追问“如果第3条流丢了你是重连还是跳过重连后怎么保证顺序类型怎么定义这个‘可能丢失’的流”——当场哑火。这不是算法题这是工程判断力。接下来的内容我会拆解真实项目中如何用TypeScript为SSE/WS流建模、如何设计容错重试机制、怎么让AI输出的非结构化文本在TS类型系统里“活下来”以及为什么Chrome 109之后WebSocket行为变化会直接导致你的AI聊天界面白屏。所有方案都来自我上半年落地的三个AI增强型管理后台不是理论推演是踩坑后抄在笔记本上的实操清单。2. 为什么“老实”会输——AI前端面试的本质已从“写代码”转向“建管道”2.1 面试官真正想看的三件事和你准备的完全错位传统前端面试像一场厨艺考核给你菜谱需求文档给你食材HTML/CSS/JS看你能不能炒出一盘色香味俱全的宫保鸡丁功能页面。但AI前端面试更像在考你修水管——面试官手里攥着一根高压AI数据流管道SSE/WS他不断往里灌水token流而你要现场装上压力表类型校验、泄压阀错误降级、分流器chunk解析和净水器Markdown/Code高亮。他不在乎你炒菜多快而在乎你装的这套系统能不能24小时不爆管。具体错位点有三个第一类型系统不再是“锦上添花”而是“生命线”。老派面试问“TS interface和type区别”你答对了拿分新面试问“AI返回的code字段可能是string、可能是{lang: ts, content: ...}对象、也可能是null你怎么定义这个类型让VS Code自动提示且编译不报错”你答不出来直接出局。因为真实场景中大模型输出极不稳定——同一prompt第一次返回纯文本第二次返回带ts包裹的代码块第三次返回JSON格式错误。TypeScript必须提前兜底而不是等runtime报错。第二网络层不再是“黑盒”而是“可编程接口”。以前你写axios.get(/api/user)面试官顶多问“怎么加loading”。现在他扔给你一段curl命令curl -N http://ai-api.com/stream?promptxxx然后问“这个-N参数代表什么如果连接idle timeout了你是等它自动重连还是主动断开后带last-event-id重试重试时怎么避免重复渲染”——这考的是你对SSE协议栈的理解深度不是调库能力。第三渲染逻辑不再是“静态挂载”而是“动态协商”。传统组件render()一次搞定AI流式渲染必须支持“增量更新状态合并中断恢复”。比如用户输入“写个Vue3 Composition API的useFetch Hook”AI先返回import { ref, onMounted } from vue;你渲染2秒后返回export function useFetch(url) {你得追加到上一行后面突然断连重连后服务器从const data ref(null);开始发你不能把前面两行删了重来得做diff合并。这要求你对DOM操作、虚拟DOM更新、以及TS类型守卫有肌肉记忆。提示很多候选人死在“以为SSE和WebSocket只是两种连接方式选一个就行”。错。它们解决的是不同维度的问题SSE适合单向、服务端推送、文本流如AI思考过程WebSocket适合双向、低延迟、二进制/文本混合如AI画图实时标注。面试官问“为什么这里用SSE不用WS”答案不是“因为简单”而是“因为AI推理流是单向不可逆的且需要HTTP兼容性某些内网环境禁WS而SSE的自动重连event id机制天然适配token流断点续传”。2.2 “不老实”的底层逻辑用工程思维替代答题思维所谓“不老实”本质是放弃“标准答案”幻觉建立“问题域-解法域”映射。举个真实例子某公司面试题是“实现一个AI代码解释器输入自然语言输出带语法高亮的代码执行结果”。老实候选人会从头写Parser试图用正则匹配js块——这注定失败因为大模型输出格式千奇百怪。不老实的做法是先定义边界明确“解释器”只要求展示不要求执行避开沙箱安全难题借力生态用highlight.js处理代码块用marked解析Markdown用TS类型守卫过滤非代码段流式适配把SSE流按\n切片每片用正则/(\w)?\n([\s\S]*?)\n/g提取失败则降级为纯文本类型兜底定义type AIChunk { type: code | text | error, content: string, lang?: string }强制所有流数据过这个schema。这个方案没用一行“高深算法”但体现了三个关键能力需求抽象能力砍掉不必要功能、工具选型能力不重复造轮子、错误防御能力类型正则双保险。面试官要的就是这个——你面对模糊需求时的第一反应不是埋头写代码而是画边界、找杠杆、设防线。我整理了近3个月高频AI前端面试题发现87%都围绕三个核心矛盾展开流式数据 vs 静态类型如何让TS类型系统适应AI输出的不确定性长连接稳定性 vs 网络环境复杂性内网代理、CDN缓存、浏览器兼容性怎么破AI输出非结构化 vs 前端渲染结构化怎么把“可能包含代码、表格、图片链接”的混杂文本安全地喂给React/Vue接下来我们就从这三个矛盾出发逐个拆解可落地的解决方案。3. TypeScript流式类型建模让AI输出在类型系统里“活下来”3.1 别再用any了用联合类型类型守卫构建AI流安全网AI输出最让人头疼的不是内容不准而是格式飘忽。今天返回{code: console.log(hello), lang: js}明天可能返回{markdown: ts\nconst x 1;\n}后天可能直接返回纯字符串这里有个bugx应该用let声明用any接TS编译器不报错但VS Code里所有智能提示消失团队协作时别人根本不知道这个变量能干嘛。用unknown每次访问都要as断言代码丑且易崩。正确解法是联合类型类型守卫渐进式解析。我们定义一个基础流式chunk类型type AIStreamChunk | { type: code; content: string; lang: string } | { type: text; content: string } | { type: error; message: string; code?: number } | { type: progress; percentage: number; step: string };关键在类型守卫函数——它不是装饰而是运行时校验function isCodeChunk(chunk: AIStreamChunk): chunk is ExtractAIStreamChunk, { type: code } { return chunk.type code typeof chunk.content string typeof chunk.lang string; } function isTextChunk(chunk: AIStreamChunk): chunk is ExtractAIStreamChunk, { type: text } { return chunk.type text typeof chunk.content string; }为什么用Extract而不用chunk.type code因为Extract能精准缩小类型范围让TS知道isCodeChunk(chunk)为true时chunk就是{ type: code; content: string; lang: string }后续.content访问无需断言。实际使用时// SSE流数据处理 const handleSSEData (data: string) { try { const parsed JSON.parse(data) as unknown; // 先尝试解析为预定义类型 if (isCodeChunk(parsed)) { renderCodeBlock(parsed.content, parsed.lang); } else if (isTextChunk(parsed)) { renderTextBlock(parsed.content); } else if (isErrorChunk(parsed)) { showError(parsed.message); } } catch (e) { // 解析失败降级为纯文本 renderTextBlock(data); } };注意JSON.parse(data) as unknown是必须的。直接as AIStreamChunk会绕过类型检查一旦后端返回格式不符TS编译通过但runtime崩溃。as unknown再走类型守卫才是安全路径。3.2 处理“流式中断”用Partial 可选链打造韧性类型SSE常见错误stream disconnected before completion: idle timeout waiting for sse本质是服务端心跳超时断连。此时前端收到的可能是一个“半截”的JSON{type:code,content:console.log(后面没了。如果类型定义是{ type: code; content: string; lang: string }这个半截数据连JSON.parse都过不去更别说类型校验。解决方案是用Partial 定义“可能不完整”的中间态// 定义“正在接收中”的类型 type PartialAIChunk PartialOmitAIStreamChunk, type { type?: AIStreamChunk[type] }; // 实际解析时允许缺失字段 const parsePartialChunk (data: string): PartialAIChunk { try { return JSON.parse(data) as PartialAIChunk; } catch { return { type: text, content: data }; } }; // 渲染时用可选链安全访问 const renderChunk (chunk: PartialAIChunk) { if (chunk.type code chunk.content?.length) { // content?.length 确保content存在且非空 highlightCode(chunk.content, chunk.lang ?? plaintext); } };这里PartialOmitAIStreamChunk, type的意思是除了type字段必须存在用于判断类型其他字段都允许缺失。chunk.content?.length的可选链操作避免了Cannot read property length of undefined错误。这是TS在流式场景下的核心优势——编译期就能捕获潜在空值而不是等用户点击才报错。3.3 高级技巧用Template Literal Types约束AI输出格式有些AI服务端会约定输出格式比如强制代码块用lang\ncontent\n包裹。这时可以用TS 4.1的模板字面量类型做更严格的校验// 定义合法的代码块格式 type CodeBlock ${string}\\\${string}\n${string}\n\\\${string}; // 类型守卫检测是否为合法代码块 function isCodeBlock(str: string): str is CodeBlock { return /^.*[\s\S]*?\n[\s\S]*?\n.*$/.test(str); } // 使用时 if (isCodeBlock(rawText)) { const [, lang, content] rawText.match(/(\w)\n([\s\S]*?)\n/) ?? []; // lang和content此时必有值TS能推导出非undefined renderCode(content, lang); }这个技巧在面试中很亮眼——它展示了你不仅会用TS还懂怎么用高级特性把“字符串处理”变成“类型安全操作”。注意正则中的捕获组(\w)和([\s\S]*?)会被TS推导为string所以lang和content无需断言。4. SSE与WebSocket实战选型、连接、容错、调试全链路4.1 SSE vs WebSocket什么时候该用哪个一张表说清维度SSE (Server-Sent Events)WebSocket通信模式单向服务端→客户端双向全双工协议层HTTP/1.1 或 HTTP/2独立协议ws://, wss://适用场景AI思考过程流式输出、日志推送、通知广播AI实时协作编辑、画图标注、语音转文字实时流浏览器兼容性Chrome 6Firefox 6Safari 12.1iOS 12.2全平台支持包括IE10重连机制浏览器原生支持自动带Last-Event-ID需手动实现需维护连接状态数据格式文本UTF-8天然适配JSON/Text二进制或文本需自行序列化CDN/代理友好度高走HTTP穿透性强低部分CDN不支持WS升级内存占用低事件流无连接状态较高维持socket连接关键结论90%的AI前端面试题中的“流式输出”默认应选SSE。理由很实在AI推理是单向的你不需要发指令给模型那是API调用层的事内网环境常禁用WebSocket但SSE走HTTP端口几乎无阻Last-Event-ID机制让断连后自动从断点续传比WebSocket手动维护offset简单得多Postman、curl都能直接测试调试成本低。WebSocket更适合“AI人”协同场景比如用户拖拽一个UI组件AI实时生成对应Vue代码并高亮修改位置——这时需要前端发拖拽坐标AI回代码块双向通信不可少。4.2 SSE连接实战从创建到重连的完整生命周期SSE连接看似简单但细节决定成败。以下是生产级SSE封装基于原生EventSourceclass AIStreamClient { private eventSource: EventSource | null null; private retryCount 0; private readonly maxRetry 3; private readonly retryDelay 1000; // ms connect(url: string, onMessage: (chunk: AIStreamChunk) void) { // 关闭旧连接 this.disconnect(); // 创建新EventSource this.eventSource new EventSource(url, { withCredentials: true // 如需cookie认证 }); // 监听消息事件 this.eventSource.addEventListener(message, (e) { try { const chunk JSON.parse(e.data) as unknown; if (this.isValidChunk(chunk)) { onMessage(chunk as AIStreamChunk); } } catch (err) { console.warn(SSE parse error:, err, e.data); // 降级处理把原始data当text chunk onMessage({ type: text, content: e.data }); } }); // 监听错误连接失败、网络中断 this.eventSource.addEventListener(error, (e) { console.error(SSE error:, e); this.handleConnectionError(); }); // 监听open连接成功 this.eventSource.addEventListener(open, () { console.log(SSE connected); this.retryCount 0; // 重置重试计数 }); } private isValidChunk(chunk: unknown): chunk is AIStreamChunk { // 类型守卫校验同前文 return typeof chunk object chunk ! null type in chunk typeof (chunk as any).type string [code, text, error, progress].includes((chunk as any).type); } private handleConnectionError() { if (this.retryCount this.maxRetry) { this.retryCount; console.log(SSE retry ${this.retryCount}/${this.maxRetry}); setTimeout(() { // 重新connectEventSource会自动带上Last-Event-ID this.connect(this.eventSource?.url || , () {}); }, this.retryDelay * this.retryCount); // 指数退避 } else { console.error(SSE max retry exceeded); // 触发全局错误状态 this.onConnectionFailed?.(); } } disconnect() { if (this.eventSource) { this.eventSource.close(); this.eventSource null; } } onConnectionFailed?: () void; }重点解析几个关键点withCredentials: trueAI服务常需登录态必须开启否则跨域请求不带cookiee.data解析异常处理SSE的data:字段可能包含换行符JSON.parse会失败必须try-catch并降级Last-Event-ID自动携带EventSource规范要求浏览器在重连时自动在HTTP Header中带上上次收到的id:字段服务端据此续传无需前端干预指数退避重试retryDelay * this.retryCount避免雪崩重连第一次1s第二次2s第三次3sisValidChunk类型守卫确保只有合法chunk才触发业务逻辑过滤掉服务端发的event: ping等控制消息。4.3 WebSocket连接实战应对Chrome 109的兼容性陷阱Chrome 109对WebSocket做了重要变更默认启用permessage-deflate扩展且要求服务端必须响应Sec-WebSocket-Extensions头。如果后端没配前端new WebSocket(url)会直接报错WebSocket connection to xxx failed且控制台无详细错误信息——这是2023年最坑的兼容性问题。解决方案分两端前端兼容处理// 创建WS时禁用压缩如果后端不支持 const ws new WebSocket(wss://ai-api.com/ws, { // Chrome 109 默认启用压缩显式禁用 perMessageDeflate: false }); // 或者更稳妥用try-catch捕获连接失败降级到SSE try { ws new WebSocket(url); } catch (e) { console.warn(WebSocket failed, fallback to SSE); this.fallbackToSSE(); }后端配置示例Node.js ws库const WebSocket require(ws); const wss new WebSocket.Server({ port: 8080, // 必须显式配置permessage-deflate perMessageDeflate: { zlibDeflateOptions: { chunkSize: 1024, memLevel: 7, level: 3 }, zlibInflateOptions: { chunkSize: 1024, windowBits: 15 }, // 允许客户端发起压缩 clientNoContextTakeover: true, serverNoContextTakeover: true, clientMaxWindowBits: 15, serverMaxWindowBits: 15, // 强制启用 enabled: true } });另一个陷阱是WebSocket子协议subprotocol。AI服务端可能要求客户端声明ai-v1子协议// 声明子协议服务端会校验 const ws new WebSocket(wss://ai-api.com/ws, [ai-v1]); ws.onopen () { console.log(Connected with subprotocol:, ws.protocol); };如果服务端配置了ai-v1但前端没声明连接会立即关闭。面试官常问“为什么WebSocket连接秒断”答案往往就在这里。4.4 调试利器Postman Chrome DevTools实战指南调试SSE/WS流式接口不能只靠console.log。必须掌握专业工具Postman调试SSE新建RequestMethod选GET在Body标签页切换到noneSSE不用body在Headers添加Accept: text/event-stream发送请求Postman会持续接收data:消息右下角显示连接状态关键技巧在Tests脚本中写console.log(pm.response.text());可查看原始流数据。Postman调试WebSocketPostman 10.18原生支持WebSocket新建WebSocket Request填入wss://xxx点击Connect连接成功后可在下方发送JSON消息查看Messages面板收发消息一目了然。Chrome DevTools深度调试Network标签页Filter选WS或SSE点击连接右侧Messages显示收发帧对于SSEData列显示data: {...}内容对于WS点击帧可查看Payload原始二进制或文本关键技巧右键帧 →Copy as fetch可快速复现请求。注意Chrome 109的WebSocket调试有个隐藏bug——如果服务端没正确响应Sec-WebSocket-ExtensionsDevTools Network面板可能不显示该连接只在Console报错。此时必须用chrome://net-internals/#websockets查看底层日志。5. 流式渲染与错误处理让AI输出“看得见、稳得住、修得了”5.1 分块渲染策略从“整块刷新”到“增量追加”的范式转移传统前端渲染是“请求-等待-替换DOM”// 老做法等全部AI结果回来再渲染 const response await fetch(/api/ai).then(r r.json()); document.getElementById(output).innerHTML renderMarkdown(response.content);AI流式渲染必须改为“边收边渲”// 新做法SSE每来一块追加到DOM let outputEl document.getElementById(output); let currentContent ; const appendChunk (chunk: AIStreamChunk) { if (chunk.type code) { // 用precode标签追加保留换行缩进 const codeEl document.createElement(pre); const codeInner document.createElement(code); codeInner.textContent chunk.content; codeInner.className language-${chunk.lang}; codeEl.appendChild(codeInner); outputEl.appendChild(codeEl); } else if (chunk.type text) { // Markdown解析后追加 const html marked.parse(chunk.content); const tempDiv document.createElement(div); tempDiv.innerHTML html; outputEl.appendChild(tempDiv); } // 滚动到底部 outputEl.scrollTop outputEl.scrollHeight; };但这样有个问题如果AI输出的是“完整代码块”但分多次推送如const a 、1 、2;直接追加会导致语法高亮错乱。解决方案是缓冲区分隔符识别class StreamBuffer { private buffer ; private readonly delimiter \n; // 按行分割 push(data: string) { this.buffer data; const lines this.buffer.split(this.delimiter); // 保留最后一行在buffer中可能不完整 this.buffer lines.pop() || ; return lines.filter(line line.trim().length 0); } getRemaining() { return this.buffer; } } // 使用 const buffer new StreamBuffer(); const handleSSEData (data: string) { const lines buffer.push(data); lines.forEach(line { const chunk parseLineAsChunk(line); // 解析单行 appendChunk(chunk); }); };这样const a 不会单独渲染等到1 2;一起到来再合并为const a 1 2;整体高亮。5.2 错误处理黄金法则三明治策略降级-上报-恢复AI流式交互必然出错关键是怎么让用户无感。我总结出“三明治错误处理”上层降级视觉上不中断用占位符/加载态过渡中层上报静默收集错误日志供后端优化模型下层恢复自动重连或切换备用通道。具体实现// 上层UI降级 const renderErrorPlaceholder (message: string) { const el document.createElement(div); el.className ai-error-placeholder; el.innerHTML div classerror-icon⚠️/div div classerror-text${message}/div button classretry-btn重试/button ; el.querySelector(.retry-btn)?.addEventListener(click, () { this.restartStream(); // 重连逻辑 }); outputEl.appendChild(el); }; // 中层错误上报不阻塞主流程 const reportAIError (error: Error, context: any) { // 发送到监控系统带traceId便于追踪 fetch(/api/error-report, { method: POST, body: JSON.stringify({ error: error.message, stack: error.stack, context, timestamp: Date.now() }) }).catch(() {}); // 上报失败不抛错 }; // 下层自动恢复 class AIStreamManager { private streamClient: AIStreamClient; private isRecovering false; handleStreamError(error: Error) { if (this.isRecovering) return; this.isRecovering true; renderErrorPlaceholder(AI思考中请稍候...); // 3秒后自动重试 setTimeout(() { this.streamClient.connect(this.currentUrl, this.onMessage); this.isRecovering false; }, 3000); } }提示面试官常问“用户看到错误提示后点了重试但第二次又失败怎么办”。答案不是“再弹一次提示”而是“记录失败次数第3次失败后自动降级到本地规则引擎如用正则匹配常见问题”体现工程闭环思维。5.3 实战避坑那些让AI前端项目上线即崩的细节根据我踩过的坑列出5个血泪教训坑1SSE连接数限制浏览器对同一域名SSE连接数有限制通常6个。如果页面开多个AI对话窗口第7个会pending。✅ 解决方案全局单例管理SSE连接用Mapstring, EventSource按session ID复用连接。坑2WebSocket心跳超时WS连接空闲2分钟会被代理服务器断开。✅ 解决方案前端每90秒发ping消息服务端回pong保持连接活跃。坑3TypeScript版本冲突vue-tsc: ^1.8.27和typescript: ^5.3.3组合在某些项目中会报Cannot find module typescript。✅ 解决方案锁定TS版本npm install typescript5.3.3 --save-dev并在vue-tsc配置中指定typescript: ./node_modules/typescript。坑4Electron打包后SSE失效Electron 22默认禁用file://协议的SSE因安全策略。✅ 解决方案启动时加参数--unsafely-treat-insecure-origin-as-securefile://或改用http://localhost作为开发服务器。坑5AI输出含XSS风险大模型可能返回scriptalert(1)/script直接innerHTML执行。✅ 解决方案所有AI输出必须过DOMPurify净化import DOMPurify from dompurify; const cleanHtml DOMPurify.sanitize(dirtyHtml); outputEl.innerHTML cleanHtml;6. 面试高频问题与参考答案把“不老实”变成得分点6.1 “为什么用SSE不用WebSocket”——标准答案之外的真实考量老实答案“SSE更简单WebSocket太重。”不老实答案我的回答“首先确认需求这是AI推理流单向、文本为主、需HTTP兼容。SSE天然满足——它的Last-Event-ID机制让断连续传开箱即用而WebSocket需要自己维护offset和重连状态。其次看部署环境我们客户内网用F5负载均衡它默认不支持WS upgrade但SSE走HTTP GET零配置穿透。最后是调试成本Postman和curl直接测SSE而WS需要专门客户端。当然如果需求变成‘AI实时协作画板’那必须切WebSocket因为需要双向低延迟。”这个回答展示了三层思维需求分析单向/双向、环境约束内网/F5、工程权衡调试成本。面试官听到这里基本就点头了。6.2 “TypeScript如何处理AI返回的不确定JSON”——展示类型系统深度老实答案“用any然后运行时判断。”不老实答案我的回答“分三层防御第一层是联合类型AIStreamChunk定义所有可能结构第二层是类型守卫isCodeChunk()做运行时校验确保分支内类型精准第三层是Partial 处理流式中断用可选链chunk.content?.length避免空指针。更重要的是我们把类型定义和AI Schema绑定——后端Swagger文档里每个endpoint的response schema自动生成TS类型用swagger-typescript-api工具保证前后端类型永远一致。这样即使AI输出变花样TS编译器第一时间报警而不是等用户点开页面才崩溃。”这里提到了自动化工具swagger-typescript-api暗示你有工程化思维不是手写类型。6.3 “流式渲染时DOM频繁更新卡顿怎么办”——性能优化实战老实答案“用debounce。”不老实答案我的回答“debounce会丢数据AI流式不能丢。我们用requestIdleCallback做帧级调度每收到10个chunk或者每16ms1帧批量渲染一次。核心代码let pendingChunks: AIStreamChunk[] []; const renderBatch () { if (pendingChunks.length 0) return; // 批量DOM操作 pendingChunks.forEach(chunk appendChunk(chunk)); pendingChunks []; }; const scheduleRender () { if (requestIdleCallback in window) { requestIdleCallback(() renderBatch(), { timeout: 1000 }); } else { setTimeout(renderBatch, 0); } }; // 收到chunk时 pendingChunks.push(chunk); if (pendingChunks.length 10) scheduleRender();另外我们用DocumentFragment做离屏渲染避免重排重绘。实测1000行代码流式渲染FPS稳定在58。”提到requestIdleCallback和DocumentFragment证明你真做过性能优化不是纸上谈兵。6.4 “如果AI服务挂了前端怎么兜底”——体现产品思维老实答案“显示错误提示。”不老实答案我的回答“分三级兜底第一级是本地缓存——把最近10次成功AI响应存localStorage服务不可用时返回相似历史结果第二级是规则引擎——对常见问题如‘怎么重置密码’用正则匹配关键词返回预置答案第三级是降级入口——在错误提示里放个‘人工客服’按钮直连在线客服系统。最关键的是所有兜底逻辑都埋点统计‘AI不可用时用户点击人工客服的比例’这个数据驱动我们和AI团队一起优化SLA。上周我们把兜底命中率从32%降到8%靠的就是这个闭环。”用数据说话把技术方案和业务指标挂钩这才是高级工程师的表达方式。7. 最后一点个人体会AI前端不是取代而是“增强”写完这篇我关掉编辑器打开自己正在做的AI代码助手项目。它用SSE接收大模型输出用TypeScript类型守卫过滤非法chunk用marked解析Markdown