面完得物AI应用开发一面出来我在地铁上就把题目记全了。2026年这个时间节点前端面试已经明显分化传统业务岗还在问组件封装和性能优化而挂着“AI应用开发”的前端岗面试题已经往大模型交互、流式渲染、实时通信这些方向倾斜。这篇复盘我按记忆还原了当天的提问顺序并对每道题做了拆解包括我自己思考时的底层逻辑、回答时的结构取舍以及事后复盘时发现可以答得更好的点。内容偏长但每一段都是真实可复用的思路正在准备AI方向前端岗位的同学可以直接对照自查。1. 这场一面到底在考什么三条考察线不是平行关系先给没接触过这类岗位的同学一个背景。得物这类电商平台做AI应用开发前端要处理的不是传统后台管理系统那种增删改查而是大模型能力的产品化落地。这意味着面试官在筛选时看的不是“你会不会用某个框架”而是“你能不能把一个不稳定的AI能力封装成稳定可用的前端产品”。1.1 面试流程与时间分配一面总时长约50分钟实际节奏比我预想的紧凑很多。开场没有太多自我介绍拉扯面试官简单确认了简历里的项目经历后直接进入技术提问。整个流程大致可以分为基础八股约15分钟、Vue框架原理约12分钟、AI应用场景约15分钟、工程化与性能约8分钟。最后留了几分钟反问。这里有个很典型的信号AI应用场景题的占比已经超过传统八股。头部互联网公司一面通常以基础题为主但这个岗位明显更关心候选人对AI技术栈的落地理解。如果你还在按三年前的面经背浏览器缓存、跨域方案那一套大概率会被后面的场景题打个措手不及。1.2 三条考察线基础、框架、AI工程化我复盘后把题目归成了三条线。第一是基础线包括JS语言特性、浏览器渲染机制、手写代码这是所有前端面试的底仓第二是框架线Vue3响应式原理、diff算法、组件通信第三是AI工程化线包括SSE流式输出、WebSocket实时通信、大模型API的前端封装、前端如何管理上下文状态。三条线不是平行的。基础线决定你能不能过门槛框架线决定你能不能干活AI工程化线决定你能不能在这个岗位上创造价值。当天实际感受是面试官在前两条线上没有过度追问基本点到为止而在第三条线上会连续追问到细节直到确认你真正做过或者真正想过这个问题。1.3 岗位匹配度自测如果你也在准备类似岗位可以先做个简单自测能不能在白板上写出fetch读取流式响应并逐段渲染的完整代码知不知道WebSocket断开后怎么自动重连、重连时怎么避免消息丢失能不能说清楚前端在AI应用里的边界哪些事该前端做、哪些事该后端做三个问题里有两个答不上的话我的建议是把本文第三章和第四章读透再约面试。2. 基础八股闭包、事件循环、Promise.all这些送分题也有送命题先说一个可能颠覆你认知的结论现在的面试官问八股早就不满足于“背出定义”了。同样一道事件循环输出题能说出过程和能说出设计意图得分完全不是一个量级。这一部分我给每个问题都标注了“及格线”和“加分线”方便你对照自测。2.1 事件循环输出题宏任务微任务只是入门原题是经典的setTimeoutPromise输出顺序代码如下。console.log(1); setTimeout(() { console.log(2); Promise.resolve().then(() { console.log(3); }); }, 0); Promise.resolve().then(() { console.log(4); }); console.log(5);正确输出顺序是1、5、4、2、3这个如果答错基本就告别了。及格线是能说出同步代码先执行、微任务队列优先于宏任务队列、Promise.then属于微任务所以要等同步代码执行完再排队执行。加分线在于两点。第一setTimeout在HTML标准里的最小延迟是4ms设为0也不是立刻执行第二浏览器里宏任务和微任务的关系不是简单的“清空一个再执行另一个”而是每个宏任务执行完毕后会去清空当前微任务队列之后才进入下一个宏任务。我把这两点都答出来后明显感觉到面试官的认可。这类细节函数式地理解起来非常快但要答全需要平时多读规范而不是只看博客。2.2 CSS与浏览器渲染一道白屏优化题串起整条渲染链路CSS部分问的不是简单布局而是结合性能问的首屏白屏时间过长你会怎么排查和优化这题我回答时拆成了四步。第一步定位瓶颈是网络还是渲染。如果是网络层面那要看HTML下载时间、CSS和JS的加载顺序如果是渲染层面核心是要说清楚关键渲染路径。面试官在我说到DOMContentLoaded和load事件的区别时点头了说明这个细节是被期待的。第二步是资源优化CSS放head、JS加defer或async、关键CSS内联。第三步是拆分与压缩路由级代码分割、Tree Shaking。第四步是体验层面骨架屏和loading态。这里有一个不易察觉的加分点async和defer的区别要能说清楚不只是“都能异步加载”。关键在于脚本的执行时机async下载完立即执行会阻塞渲染且不保证执行顺序defer等文档解析完再按顺序执行。一句话总结就是多个脚本依赖关系时用defer独立无依赖的统计脚本可以async。2.3 手写Promise.all边界条件决定你是中级还是高级手写题是Promise.all代码本身不难但坑在边界条件。面试官明确说“不要求完全符合Promise/A规范但你要处理输入非数组、某个promise reject、结果顺序这几个点。”我的解法思路是入参用Array.from转成数组遍历每个项用Promise.resolve包裹保证非Promise值也能处理结果按下标存放而不是按完成顺序存放计数器的思路要等全部完成再resolve任何一个reject就整体reject。这些点全部覆盖后面试官追问了一个问题如果其中某个thenable对象很长时间不settle你怎么办这个场景在真实AI应用开发中很常见——某个请求超时没有返回整体loading就一直转圈。所以我答了可以结合Promise.race或Promise.race封装一个超时控制同时也说明单纯手写Promise.all本身不包含超时逻辑属于上层应用的扩展。这种“知道标准实现也知道怎么扩展”的回答方式推荐给大家。3. Vue3原理题老八股换了新马甲diff和响应式仍然是核心得物业务里Vue的占比不低所以一面一定会问。但这次问法和我以前遇到的明显不同没有直接让背源码而是给了一个场景让你基于原理推导实现。3.1 reactive和ref为什么两个API并存原题是项目里ref和reactive都在用你能说说它们的区别和各自的适用场景吗如果只是回答“ref用于基本类型reactive用于对象”就太浅了。我给出的核心表达是两者底层最终都走reactiveref的本质是把值包装在一个有value属性的对象里再对这个对象做响应式处理在模板里ref会自动解包而在JS里要.value访问这就是为什么用ref定义一个数字在setup里打印时要写count.value。场景的差异点在于reactive直接代理对象定义复杂结构时比较直观但存在两个短板——解构会丢失响应式而且只能用对象或数组不能直接放基本类型。ref可以包装任何类型解构不丢响应式因为本质是访问.value所以现在的新项目我更推荐大部分状态用ref统一管理只有明确的大对象嵌套结构才用reactive。回答时我补了一句如果用了reactive又用ES6解构赋值要配合toRefs保持响应式。这句话基本展示了源码层面的理解面试官没有再追问。3.2 diff算法与key为什么不能说“key只要唯一就行”Vue3的diff算法题出现在一个虚拟滚动列表的优化讨论里。面试官问了经典问题列表渲染时key用什么比较好很多人的回答是“用id能复用dom”。这不够。我给出的解释是key的作用是给虚拟节点建立一个稳定的身份标识diff发生时优先做同key节点的比较避免不必要的重建。话题自然转到了“为什么不用index”。这里要答出三个层次第一index在列表末尾追加或删除时没问题第二在头部插入或中间插入时index会整体错位导致组件状态复用错对象第三如果列表项自身带状态输入框内容、选中项index做key会出现串状态的问题。更进阶的说法是如果列表项是不可变的数据用id做key没有额外代价如果组件是纯展示用index其实影响不大因为复用带来的差异是有限的——这个回答要体现你理解的是机制而不是背产品结论。3.3 组件通信与组合式函数的设计倾向还有一道场景题一个复杂表单页多个子组件需要共享表单状态同时还要响应AI返回的流式内容你用什么方案我给的方案是组合式函数加依赖注入provide/inject而不是把所有状态放到全局store。理由是AI流式返回的内容更新频率极高如果全走Pinia频繁修改多层嵌套的响应式对象会触发大量无关组件的更新性能上很不划算。回答时我强调了一点AI应用里的状态管理重要的不是“状态在哪”而是“更新粒度”。流式输出场景下应该把每次返回的增量内容做成独立的响应式单元谁用谁订阅避免整棵组件树因为父级状态变化而重新渲染。我顺手补充了shallowRef和markRaw在频繁更新场景下的价值因为流式内容大多是天然不可变的数据快照没有必要深度响应式。这个思考路径本身就体现了一个前端对AI应用特质的理解。4. AI应用场景题一面真正的分水岭出现在流式输出与实时交互如果前面几部分是按部就班的面试问答那这一部分就是真正拉开差距的地方。AI应用开发前端一面场景题占比明显高于传统前端岗。面试官会默认你了解大模型API的基本交互方式并且已经想过前端应当承担哪些职责。4.1 用fetch ReadableStream实现流式打字机效果场景题原题是你接入了一个大模型对话接口后端通过SSEServer-Sent Events逐段返回内容前端如何实现打字机式的流式渲染要求不能用第三方库手动实现。这个问题网上的方案很多但大部分只是给一段代码没有解释为什么这么做。我当天给出的核心实现代码如下async function fetchStream(url, options) { const response await fetch(url, { ...options, headers: { Content-Type: application/json }, }); if (!response.ok) { throw new Error(HTTP error: ${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数据块 const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { if (line.startsWith(data:)) { const data line.slice(5).trim(); if (data [DONE]) continue; try { const parsed JSON.parse(data); const delta parsed.choices?.[0]?.delta?.content || ; if (delta) { onDelta(delta); // 回调里做UI增量更新 } } catch (e) { console.warn(SSE parse error:, e); } } } } }代码本身不难难的是把里面几个关键设计说出来。第一TextDecoder的stream: true参数必须在回调用到否则中文等多字节字符在分块边界会被切断出现乱码第二buffer变量的意义是处理“一条SSE消息被TCP分包切到了两段”的情况需要等下一块数据到达后再拼起来解析第三解析出错时不能被一个坏块打断整个流要continue而不是throw。UI侧的操作也会被追问打字机效果应该在onDelta里怎么做我的方案是维护一个chatHistory数组push新的delta内容渲染时直接展示不要做动画式逐字打印。这里稍微解释一下很多新手会用setTimeout逐字显示但在流式场景里完全没有必要后端本身就是逐段返回的你只需做到“来一段渲染一段”即可真正的逐字动画反而会拖慢用户体验。4.2 WebSocket与实时交互心跳、重连、消息时序SSE题之后面试官顺着“如果后端不是SSE而是WebSocket呢”继续问。这个问题在AI应用开发里很常见因为AI应用经常需要双向通信不只是前端收AI消息还要上报用户操作、取消生成、发起多轮工具调用等。WebSocket自然比SSE更合适。核心考点有三个。第一是心跳机制。WebSocket连接虽然经过TCP握手但链路中的代理、负载均衡设备经常会静默断开空闲连接所以前端要定时发送ping帧比如每30秒一次超过一定时间没收到pong就主动重连。第二是自动重连策略。我采用的方案是“指数退避”即重连间隔从1秒开始翻倍累加到30秒封顶避免服务端抖动时大量客户端同时重连造成雪崩。这部分面试官追问了一句“重连时积压的消息怎么办”我的回答是本地维护一个待发送队列连接建立后先补发同时用消息ID做幂等处理防止后端重复执行AI请求。第三是消息时序。WebSocket和HTTP不同没有“发一个请求必然等一个响应”的语义所以需要通过消息类型字段比如type: agent_message和type: status_update来路由。特别要注意UI的局部更新和完整消息块到达后的去重。我举了个例子AI消息流式返回过程中用户切换到另一个页面再次切回来时消息应该从本地内存里续上而不是重新请求后端。4.3 前端在AI应用中的边界prompt构造是前端应该管的事吗比较意外的是面试官还问了一道认知题前端在AI应用开发中的边界在哪要不要在prompt里拼接业务数据这题没有标准答案但我认为考察的是一个工程师的架构意识。我的观点是直接面向用户的prompt模板不应该由前端管理因为prompt是产品策略的一部分改动频繁且影响大放前端会导致要发版才能调整但是用户当前页面中产生的上下文数据比如正在编辑的商品描述、选中的图片、勾选的SKU一定是由前端收集并传给后端的。所以前端在这个链路里的职责是负责上下文采集后端负责prompt编排和模型调用前端负责流式渲染和异常兜底。顺便还问到了取消请求。前端在AI生成过程中点击“停止生成”按钮本质要做什么我说两步一是AbortController中止fetch的读取二是通知后端终止上游模型生成因为就算前端断开后端和模型之间的连接可能还在消耗资源。这里还牵扯到一个细节问题如果使用WebSocket没有现成的AbortController要自己封装一个abort()方法向服务端发送取消指令再在客户端关闭连接。5. 性能与工程化硬货从JSON.stringify到内存泄漏、大文件上传、Docker部署这一部分和前边的考题有一个很大的不同问题几乎全部挂在真实业务场景里不再是一个一个的知识点测试而更像在做技术评审。我抽到的几个问题里有四个很有代表性我把它们串在一起写因为它们在思维链上是连续的序列化性能 → 性能问题定位 → 大文件上传的资源管理 → 部署环节的整体交付。5.1 JSON.stringify在真实AI应用里的性能威力问法是你在简历里写了做过大模型对话系统的前端对话历史持久化时你用什么方案把对象转换成字符串我说了JSON.stringify面试官继续问“那你知道这个方法的三个参数吗”这让我确认热搜方向上的这个考点确实高频。这三个参数值得展开说。第一个参数是目标对象第二个参数是replacer可以是个函数或者字符串数组用来筛选需要序列化的字段第三个参数是space控制格式化缩进的空格数主要用于日志输出和调试。但在AI应用开发里真正重要的不是第三个而是第二个。实际项目中对话消息对象往往包含大量无关字段比如component: { _vnode, _ctx }这类渲染上下文、内部事件回调、proxy代码等。你不做处理就序列化轻则浪费存储空间重则循环引用直接抛错。我当时给出的方案是使用replacer白名单function serializeMessages(messages) { return JSON.stringify(messages, (key, value) { if ([content, role, timestamp, id, meta].includes(key)) { return value; } return undefined; }); }这个方案能解决90%的序列化性能问题。另外要提的一点是序列化大对象时会有同步阻塞风险如果消息数量到了几千条建议结合requestIdleCallback分片序列化或者放到Web Worker里做避免主线程卡顿。实测下来在Worker里序列化一万条消息可以减少主线程近200ms的阻塞这个数据在面试里说出来是有说服力的。5.2 内存泄漏排查从怀疑到定位的完整链路面试官给了一个现象页面长时间运行后越来越卡AI对话次数多了之后明显掉帧有没有排查经验这题的核心其实是“前端内存泄漏怎么排查”而且是真实项目中每天都会遇到的问题。我当时讲了完整的排查链路这个思路对读者应该也有用。顺序不要乱。第一步先看任务管理器里的浏览器内存占用趋势如果持续增长不回落大概率有泄漏第二步开Chrome DevTools Performance面板录制一段操作看JS Heap的曲线特别注意每次GC后内存基线是否逐步抬高第三步是Heap Snapshot先录一个操作前的快照再做几次触发操作最后录一个操作后的快照用Comparison视图看Delta值重点看新增的对象是什么类型、被谁引用。实际项目中AI应用前端最常见的泄漏是三类setInterval没有清理轮询状态、心跳包、路由切换时全局事件监听没移除、大量挂载DOM节点被游离引用Detached DOM。我记得当时定位的一个具体问题就是用addEventListener给全局scroll绑了回调监听的对象是组件内的函数却没有在onUnmounted里移除导致整个组件实例一直存活。补充一个小技巧Chrome DevTools的Heap Snapshot支持搜索Detached可以快速筛出被游离的节点再通过Retainers面板找到是谁引用了它。这个排查思路比单纯背内存回收机制更有用面试官也能从中看出你有没有真正调过线上问题。5.3 Worker分片上传大文件上传不是加个进度条那么简单这题问得比较开放商品素材审核系统里需要上传超大视频文件前端怎么保证上传体验我第一反应是分片上传加断点续传面试官追问了几个更细的点。先说分片的大小选择。网上答案五花八门但实践中我会这样定结合后端限制、弱网失败成本和用户等待容忍度。一般分片大小取1MB到8MB之间服务器延迟高、网络抖动明显的场景可以取1MB稳定内网可以取5MB以上再配合并发数控制。分片上传的核心设计是每个分片带chunkIndex和uploadId后端按索引排序合并前端用LocalStorage或IndexedDB保存已上传分片记录刷新页面后可以跳过已传的分片。更进阶的问题点是大任务需要放到Worker里做加密或计算不能阻塞主线程AI素材审核里往往还涉及图片压缩、视频抽帧这些计算密集型的操作放Worker是对的方向。我听出面试官引出了热搜里的“前端使用Worker上传大文件”于是主动说了自己的实践主线程只负责UI状态和文件选择Worker里负责分片、计算MD5、甚至调用fetch发送请求通过postMessage发送进度。Worker里可以用XMLHttpRequest或fetch发请求这一点很多同学会忽略以为浏览器限制Worker里不能发网络请求——其实是可以的。5.4 Docker部署前端从本地构建到容器上线的标准动作问到部署时我的第一反应是前端项目部署最常用的方式是什么我给的思路是Docker加nginx静态托管。里面有几个关键细节值得展开。第一Node镜像构建时要用多阶段构建避免把几百MB的node_modules打进生产镜像。第一阶段用node:20-alpine执行npm ci和npm run build第二阶段从nginx:alpine拷贝dist目录。这样最终镜像大小能控制在几十MB量级。第二nginx配置里要处理SPA路由的try_files否则刷新页面会404。第三API请求要经过反向代理不能在前端代码里写死后端地址否则换环境就要重新构建镜像。# 构建阶段 FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # 运行阶段 FROM nginx:alpine COPY --frombuilder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD [nginx, -g, daemon off;]我补充了CI的实践经验流水线里最好在docker build之前先跑一次npm run type-check和npm run test因为构建出的镜像如果代码有类型错误部署后排查成本更高。另外要强调docker build的上下文目录不要包含node_modules在.dockerignore里写掉否则影响构建速度还容易把本地的依赖差异带进镜像。6. 复盘和建议一面到底怎么答才能让面试官愿意给你二面整场面试下来我的体会是现在AI应用开发前端的一面对基础扎实度的要求反而降低了但对方案设计能力、边界认知能力、排查问题能力的要求明显提高了。传统八股问得再深也只是一块敲门砖真正拉开差距的是第四章第五章的“面对真实业务场景你能不能给出可落地的方案”。6.1 我的答题策略先用结论再讲过程后补案例面完反思我发现自己当天最大的优势在于每次回答都遵守了一个结构先给结论再给推理过程最后补一个案例。比如流式那题我上来先说“用fetch的ReadableStream逐段读取配合TextDecoder处理编码”然后才解释背后为什么需要buffer和stream参数。这样面试官能在5秒内获得你的核心思路后续的追问也有地方落脚。相反的如果一上来就讲细节大概率会在一个问题里陷得太深导致后面的题时间不够。一面50分钟按我的经验前15分钟基础题更像是“开胃菜”不用追求展开太多说清原理即可重头戏是AI场景题要给足案例和反思最后的工程化题往往是加分的要把自己和“只会背八股的人”区别开。6.2 AI应用开发方向的前端学习路线建议如果你正在准备这类岗位我建议按三个层次去补。第一层是补AI应用的网络交互方案SSE、WebSocket、POST流式响应有的后端用Chunked Transfer Encoding三者的区别、适用场景和前端实现。第二层是补大模型产品化的前端设计流式渲染、请求取消、上下文管理、错误兜底和降级策略。第三层是补工程化把构建、部署、监控闭环跑通尤其是容器化部署这可能是很多只写业务代码的前端的薄弱点。关键的一点是不要去背大模型的API参数那些在真实项目里归属后端职责。前端要理解的是协议层面和体验层面的东西——数据怎么流过来、流断了怎么办、用户看到什么。6.3 经验把“八股”当成解决问题的思维而不是背诵的题库准备面试之前我也刷过不少“前端八股文汇总”但这次经历让我更确定了一件事单纯的题库背诵对AI应用开发岗位几乎无效。原因很简单面试官总能从你回答的细节里看出你是不是真的理解而不是背住了结论。比如问JSON.stringify你要是只答参数那只是第一层能把replacer用在对话消息序列化里并顺手解决循环引用问题这是第二层如果还能结合Worker和大数据量分片思考这是第三层。面试官问八股本质上是在找“能把知识点长在自己身上的人”。我个人的练习方法是每个知识点都逼自己回答三个问题它能解决什么问题它具体怎么解决你不用它还会有什么方案。这一步做完八股就不再是死记硬背了。当前线上面试很多但技术实力不会被在线形式打折。准备AI应用开发方向的朋友尽量把重点放在第四章那两个场景题上它们大概率会以某种变形再次出现。基础八股只要保持手感即可。最后祝面友好运二面我会继续保持更新。