1. 2026年面试风向八股文退场场景题当道1.1 为什么背闭包、原型链已经撑不起一场面试先说个我前阵子的真实经历。帮朋友内推了个两年经验的候选人简历上写着熟悉Vue、掌握性能优化、有组件库开发经验。一面的面试官问了三道题第一道让他讲讲字典管理这类功能模块在前端怎么设计第二道问大文件上传时怎么处理切片和并发第三道直接甩了个微前端场景问他怎么拆分业务。候选人当场愣住说自己准备的都是Vue响应式原理diff算法跨域解决方案这类题。这个场景我见过太多次了。不是说基础题不重要而是2026年这个节点面试官的提问逻辑已经变了——他们默认你基础扎实所以更想听你怎么用和为什么这么用。热搜词里那些Hzero、AnythingLLM、Dify、OnlyOffice、BPMN已经暴露了行业真实需求前端不只是写页面而是要处理复杂业务、对接AI能力、融入企业级基础设施。所以这篇面经我想换个写法不按HTML/CSS/JS/框架这种教科书目录来而是按照我在真实面试里遇到的、以及我在陪跑候选人时总结的高频提问场景来拆。每道题我都给出完整的答题思路、关键知识点和应该避开的坑。1.2 这类场景题到底在考察什么你可以把现在的面试想象成一场技术方案评审而不是考试。面试官给你一个模糊的业务背景通过你的追问来观察几个维度边界感你能不能快速识别这个需求的技术核心在哪和什么都想做的伪方案长什么样。取舍能力例如微前端用qiankun还是module federation你能不能说出选型的依据而不是背出两者差异。工程意识同样写一个上传组件你会不会先想到断点续传、并发控制、失败重试这些真实场景里的痛点。原理深度注意这里说的不是背原理而是你能否用原理来解释场景问题。比如问你SSE不只是回答EventSource能做服务器推送还要能接住断线重连时ID怎么处理这种追问。我在面试里常看到两类人。一类背题很熟但一追问就露馅因为他只记住了是什么回答不了为什么。另一类项目经验丰富但不会表达明明做过多复杂的组件库却只能讲出做了个组件库完全没有提炼出设计思路。这篇文章更适合后者——你有实战底子我帮你把表达框架顺一顺也帮前者补上从场景出发理解知识的思维方式。2. 一题串一题大文件上传、Worker和SSE的完整答题路径2.1 大文件上传切片、并发与断点续传这道题几乎成了2026年面试的标配温度计因为它太能反映一个工程师的实战深度了。很多候选人的回答停留在用FormData传文件。但面试官真正想听的链路是这样的第一步明确大在哪里。大文件上传的瓶颈不在文件本身而在网络。一个2GB的文件在弱网环境下一次性POST很容易超时、失败、整体重传。所以第一个核心动作是切片。前端用File.prototype.slice把文件切成若干固定大小的块比如每片5MB或10MB后端按片接收最后再合并。第二步并发控制。切片只是开始如果你把100个切片一次性全部发出去浏览器和服务器都扛不住。这里需要做一个并发池控制同时上传的切片数量。我一般建议3~6个太少了浪费带宽太多了容易触发服务端连接数限制。伪代码大概是这样的async function uploadInConcurrency(file, chunkSize 5 * 1024 * 1024, concurrency 4) { const chunkCount Math.ceil(file.size / chunkSize); const queue []; const tasks []; for (let i 0; i chunkCount; i) { const chunk file.slice(i * chunkSize, (i 1) * chunkSize); const task async () { const formData new FormData(); formData.append(chunk, chunk); formData.append(index, i); formData.append(filename, file.name); // 这里补充你的上传请求 }; queue.push({ index: i, task }); } // 用并发池调度queue中的任务 const workers new Array(Math.min(concurrency, chunkCount)) .fill(0) .map(async () { while (queue.length) { const item queue.shift(); await item.task(); } }); await Promise.all(workers); }第三步断点续传和秒传。断点续传的关键是服务端要知道已有哪些分片。通常做法是上传前先向后端发一个校验请求带上filename和md5或者更快的计算方式比如抽样哈希后端返回已收到的分片索引列表前端跳过这些切片再传。秒传的原理也在这里——如果后端发现整个文件的哈希都已存在直接返回文件已存在前端弹个上传成功实际没有真正传。第四步失败重试和进度。单个切片失败后要支持重试而不是整个文件推倒重来。同时XMLHttpRequest的upload.onprogress或fetch的ReadableStream都能拿到整体进度前端应把进度除以切片完成数来显示百分比。面试加分点主动说出Web Worker可以承担文件切片的哈希计算把它引导向下一题这就顺理成章地展示了你的技术视野。2.2 Web Worker从计算哈希到任务池刚才提了大文件上传里的哈希计算——对大文件做全量MD5是很耗时的几十秒到几分钟都有可能。如果跑在主线程上页面直接卡死。这时候把hash计算塞进Web Worker界面保持流畅就是标准的懒人解法。但面试官不一定止步于此他可能继续问Web Worker里能操作DOM吗能跨域请求吗Dedicated Worker和Shared Worker有什么区别答案分别是一个都不能、可以、以及适用范围不同。Worker线程没有window和document不能碰DOM但可以用fetch发请求也能通过postMessage和主线程通信。关键是通信时数据是用结构化克隆structured clone序列化的不是引用传递——这也是面试中容易忽略的细节。我在实际项目里见过有人试图在Worker里直接修改一个大对象主线程里的值纹丝不动原因就在这。其实Worker在真实项目里的用途不只是处理大文件。我在给部门搭前端中台时用Worker维护了一套心跳上报池把页面内所有埋点消息先推到Worker线程统一调度再用navigator.sendBeacon发送。这样就算某个页面卡了埋点也不会丢。这类把通用任务下沉到Worker的思路比单纯背API更容易打动面试官。2.3 SSE与EventSource不是所有实时都要WebSocket实时通信题几乎每场面试都会出现。但2026年的新趋势是面试官会主动把你往非WebSocket方案上引因为很多前端工程师一谈实时就只知道WebSocket。SSEServer-Sent Events是考察的另一个方向。我用一个生活化的类比解释WebSocket像一对一的电话双方随时说话SSE更像广播电台服务端单向往客户端播客户端只需要竖起天线听。它底层走HTTP用text/event-stream这个MIME类型前端用EventSource接口接收const evtSource new EventSource(/api/events); evtSource.onmessage (event) { console.log(event.data); };SSE的价值在面试里怎么体现关键在于场景判断。比如聊天室、白板协作需要双向高频交互用WebSocket合理但像股票行情、AI对话流式输出、系统通知这类服务端主动推送、客户端被动接收的场景SSE就足够而且实现成本低得多——不需要单独维护一个长连接协议天然支持断线重连甚至能通过HTTP/2做多路复用。这里有一个我在追问中常踩到的坑面试官问SSE断线怎么办很多人答不上来。SSE的EventSource内置了断线重连但它重连时默认不携带上次的Last-Event-ID如果你不希望客户端重连后从头接收数据就得在后端配合回传这个ID客户端在onerror里重建连接时把它带上。这个细节一展开面试官对你的评价会完全不同。3. 业务层的架构追问字典管理、微前端和BPMN流程化的底层逻辑3.1 字典管理一个小功能背后的设计分水岭热搜词里出现了前端系统管理下的字典管理一般有啥用很多人觉得这只是个CRUD但面试官能从一个简单的字典管理问到你对前端状态设计的理解。字典是什么就是一组键值对比如性别{ male: 男, female: 女 }订单状态{ 1: 待支付, 2: 已支付, 3: 已取消 }。业务系统里大量下拉框、标签、状态回显都依赖字典。一个设计糟糕的前端字典管理是每个页面各自写死改一个状态名称要全局搜索替换。而好的设计有一套统一机制。第一层字典数据从哪来。通常由后端提供接口前端在登录后或首次进入系统时拉取缓存到全局状态如Pinia或Vuex。但只做到这里还不够你需要设计字典加载中/加载失败/数据缺失的兜底状态以及字典变更后的刷新策略。第二层字典怎么用。最经典的方式是封装一个useDict钩子或DictSelect /组件传入dictType它自动渲染下拉框。这背后的抽象逻辑是类型感知——前端代码里不直接写1、2、3而是通过映射表转成可读文案杜绝魔法数字。第三层字典与权限、国际化的混搭。如果你的系统需要多语言字典值可能也要做i18n如果某些字典项只有特定角色可见还要做权限过滤。把这些点聊透面试官就知道你不是只写过增删改查而是真的思考过配置驱动的架构设计。3.2 微前端的追问拆分粒度、通信方式和部署隔离微前端是2026年热搜里的常客前端面试必有一题。但现在的题不会再问什么是微前端而是给场景。最常见的是这样一个你们有多个团队负责一个大型中后台系统每个团队用不同的技术栈发布节奏也不同怎么落地微前端答题框架可以分三层拆分的边界原则。微前端的微不是指组件级而是应用级。通常用业务域做边界比如订单域、用户域、权限域每个域独立成一个子应用。最怕的是把组件级拆成微前端搞出几百个子应用麻烦远超收益。面试时可以突出这个别过度拆分的意识这是经验分。通信方案。不同子应用之间不能共享内存所以要靠全局事件总线、URL参数、自定义事件或localStorage来传数据。现在比较成熟的做法是主应用维护一个globalState子应用通过API订阅和修改。这里可以追问一句如何在子应用卸载时清理监听器避免内存泄漏——这是真正的加分细节。部署与集成。子应用通常是独立开发、独立部署构建产物交给主应用动态加载。你可以聊qiankun的registerMicroApps也可以聊module federation的联邦模块共享依赖。注意不是让你背它们各自的API而是要比较qiankun适合物理隔离生命周期管理强的场景module federation更适合依赖共享、构建期决策的场景。选型逻辑比工具本身更值钱。3.3 BPMN定制与OnlyOffice集成非典型场景里的思路调用热搜里有BPMN自定义流程和OnlyOffice部署这类需求多数前端工程师没做过但它恰恰是2026年业务流程数字化的缩影面试官会拿来做技术广度测试。BPMN题的核心在于你如何理解一个图形化流程设计器。通常用bpmn-js这个库。但如果面试官问要改造它实现自定义审批节点怎么办你需要答出两个层次。第一层先识别bpmn-js的模块化结构它内置了Modeler、Viewer、PropertiesPanel以及各种自定义element模板的机制。第二层自定义流程本质上是数据模型驱动渲染——你在moddle里扩展元素类型定义它的属性画布上的节点只是这些属性的可视化表达。把这个抽象关系讲明白说明你有驾驭复杂开源项目的能力。OnlyOffice集成题则更偏向你是否了解在线编辑的完整链路。一般会问前端怎么集成OnlyOffice文档服务器DocEditor初始化时传入哪些参数回调怎么处理权限怎么控制。你不需要真正跑通过代码但要回答出必须区分OnlyOffice Docs服务端和前端API两个部分、以及文档保存后的回调会向callbackUrl发POST请求这个机制。把这些关键链路说出来面试官就知道你有过调研。4. 那些搜索热度高但容易翻车的新方向4.1 WebCodecs与H264解码浏览器视频处理的新考点热搜里前端js解码h264讨论度很高可能是监控播放、视频编辑、音视频会议某个场景触发的。这道题为什么容易翻车因为很多前端对视频解码的认知停留在用video标签或给播放器传URL完全不清楚浏览器底层发生了什么。WebCodecs API是2026年面试官想听到的关键词。它让浏览器原生解码能力暴露给JS你可以拿到VideoDecoder的实例喂给它EncodedVideoChunk压缩的视频数据它通过回调输出VideoFrame解压后的帧。这有什么用在WebRTC、直播、视频编辑场景不再依赖复杂的播放器或video媒体流你可以直接对每一帧做处理——比如叠加水印、做滤镜、人脸识别。答题时建议按数据流来讲采集源摄像头/文件/WebSocket收到的流→ demux得到编码帧 → VideoDecoder解码 → VideoFrame绘制到Canvas/WebGL → 再经VideoEncoder编码 → 推流或保存。这个链路说完再补充一句WebCodecs是异步API注意控制队列积压、关注decodeQueueSize就能展现出你考虑过工程落地而不是停留在demo。顺便提一嘴面试官可能顺着问H.264和H.265有什么区别、码率控制怎么做。这里的本质是编码器的复杂度不同——H.265压缩率更高、但解码更耗时硬件兼容性要考虑。结合业务场景说明什么时候选265、什么时候选264比你死记硬背技术规格强得多。4.2 AI辅助编码时代面试开始考察人与工具的分工最近的热搜词出现了大量AI开发工具的讨论2026年面试的新题目可能直接变成你在项目里怎么用AI工具这道题背后考察的不是你会不会用Copilot而是你有没有形成AI辅助但不依赖的工作流。我的理解是面试官想听到三件事什么时候该让AI写代码什么时候该自己写。比如生成表单校验规则、写正则表达式、补单元测试这些都是模式匹配型任务交给AI效率高。但涉及核心业务状态流转、支付流程、权限校验这类领域敏感的代码最好不要直接信AI必须人肉审一遍。怎么向AI描述需求。一个优秀的prompt往往包含输入输出示例、边界条件、限制清单、验收标准。在面试里提到我会把接口文档片段丢给AI让它按公司规范生成Service层代码再人工review这比只会说用ChatGPT高级得多。如何验证AI产出的正确性。这是最大的分水岭。AI生成的代码没过测试、没有覆盖率、没有类型检查你敢直接上线吗一个成熟的工程师会把它丢进CI流水线让静态检查和单测来兜底。这个思路一定要表达出来。我也建议你在面试前准备一个AI提效的实例比如用AI快速把设计稿转成Vue组件但要讲清楚AI生成的代码踩了哪些坑——比如class命名混乱、样式侵入父组件、没有处理loading态。既有落地成果又有反思过程这种回答在面试中最能加分。4.3 前端性能与SEO从改标签到观测指标前端SEO这个问题在2026年再次翻热因为越来越多的SaaS产品和内容型站点开始重视前端可检索性。面试题目可能是你们项目SEO不好怎么排查从基础的讲robots.txt、sitemap.xml、meta标签、语义化HTML、SSR/SSG。但这套标签思维在面试里很可能被追问——如果项目已经上线不能大改怎么提升SEO这就考到动态渲染利用Puppeteer或rendertron检测到爬虫UA时就返回预渲染的HTML普通用户仍是SPA。这个方案能立刻提升收录率而且不用重构。性能优化题同理我不建议死背图片懒加载、代码分割、CDN缓存这些老话。2026年更好的答法是从指标反推方案。比如提到LCPLargest Contentful Paint太慢你先用Performance API拿到真实的LCP数据再判断瓶颈是网络加载还是脚本执行有针对性地做优化——资源预加载、压缩大图、删除阻塞渲染的JS每一步都对着指标说话。这个思路比背十条优化手段高级得多。4.4 表格标签与组件表格背后的工程取舍热搜里出现了前端表格标签和前端组件库。别觉得这题简单面试官可能拿它延伸出表格性能的经典追问表格里有10万条数据你怎么渲染 注意这题跟表格标签已经没关系了考的是你对虚拟滚动、分页、Web Worker计算的理解。所以把表格标签当引子你可以准备这样一条完整链路原生table语义化最好、SEO友好适合基础数据展示。组件表格如Element Plus的el-table封装了排序、筛选、分页、虚拟滚动适合中后台。但注意组件的虚拟滚动只针对视口可见范围如果表格内一个单元格里有大量DOM比如富文本或嵌套组件性能依然会崩。大数据网格如ag-Grid、TanStack Table适合复杂表格场景。答题时要能说出为什么不能直接用el-table 分页了事——因为有时候需求要求同一屏幕展示大量行且支持行内编辑只有开启行虚拟化和单元格级渲染才扛得住。5. 我最后想和你说点实在话本来聊到上面就可以收尾了但既然题目是面经我还是想多分享一点最近陪跑候选人时总结的体会。现在的面试越来越像技术合伙人面试而非工程师招聘面试。面试官希望看到你像一个技术方案的owner而不是一个任务的executor。所以你在准备时可以把自己做过的每个项目都过一遍为什么、选型取舍、如果重来会改什么这三问。很多人忽略的另一个细节是诚实边界。技术面里最忌讳的不是答错而是不懂装懂。我见过一个候选人被追问到Worker线程池的细节时坦诚说这里我确实没在真实项目里用过只做过Demo面试官反而继续友好地引导另一个候选人不懂装懂被追问两轮之后露馅整场印象分直接崩掉。所以面对没把握的问题你可以正面回答我理解的是……但我没实际验证过比硬撑着强。最后不要把面经当成题库把它当成查漏补缺的清单。你打开这篇文章看到大文件上传、SSE断线重连、微前端通信这些点如果每一个都能不卡壳地讲出设计思路 踩坑经历 可落地的代码结构那你大概率已经通关了。如果哪一节让你觉得哦原来这里还有一层那就花一两个周末把它做一个小的Demo跑一遍。面试前用这种最小可验证的方式查漏比刷十道大厂真题更管用。祝你能把面试当成一场技术对话聊出自己的底气。 2026前端面试风向：场景题制胜，从大文件上传到微前端实战
1. 2026年面试风向八股文退场场景题当道1.1 为什么背闭包、原型链已经撑不起一场面试先说个我前阵子的真实经历。帮朋友内推了个两年经验的候选人简历上写着熟悉Vue、掌握性能优化、有组件库开发经验。一面的面试官问了三道题第一道让他讲讲字典管理这类功能模块在前端怎么设计第二道问大文件上传时怎么处理切片和并发第三道直接甩了个微前端场景问他怎么拆分业务。候选人当场愣住说自己准备的都是Vue响应式原理diff算法跨域解决方案这类题。这个场景我见过太多次了。不是说基础题不重要而是2026年这个节点面试官的提问逻辑已经变了——他们默认你基础扎实所以更想听你怎么用和为什么这么用。热搜词里那些Hzero、AnythingLLM、Dify、OnlyOffice、BPMN已经暴露了行业真实需求前端不只是写页面而是要处理复杂业务、对接AI能力、融入企业级基础设施。所以这篇面经我想换个写法不按HTML/CSS/JS/框架这种教科书目录来而是按照我在真实面试里遇到的、以及我在陪跑候选人时总结的高频提问场景来拆。每道题我都给出完整的答题思路、关键知识点和应该避开的坑。1.2 这类场景题到底在考察什么你可以把现在的面试想象成一场技术方案评审而不是考试。面试官给你一个模糊的业务背景通过你的追问来观察几个维度边界感你能不能快速识别这个需求的技术核心在哪和什么都想做的伪方案长什么样。取舍能力例如微前端用qiankun还是module federation你能不能说出选型的依据而不是背出两者差异。工程意识同样写一个上传组件你会不会先想到断点续传、并发控制、失败重试这些真实场景里的痛点。原理深度注意这里说的不是背原理而是你能否用原理来解释场景问题。比如问你SSE不只是回答EventSource能做服务器推送还要能接住断线重连时ID怎么处理这种追问。我在面试里常看到两类人。一类背题很熟但一追问就露馅因为他只记住了是什么回答不了为什么。另一类项目经验丰富但不会表达明明做过多复杂的组件库却只能讲出做了个组件库完全没有提炼出设计思路。这篇文章更适合后者——你有实战底子我帮你把表达框架顺一顺也帮前者补上从场景出发理解知识的思维方式。2. 一题串一题大文件上传、Worker和SSE的完整答题路径2.1 大文件上传切片、并发与断点续传这道题几乎成了2026年面试的标配温度计因为它太能反映一个工程师的实战深度了。很多候选人的回答停留在用FormData传文件。但面试官真正想听的链路是这样的第一步明确大在哪里。大文件上传的瓶颈不在文件本身而在网络。一个2GB的文件在弱网环境下一次性POST很容易超时、失败、整体重传。所以第一个核心动作是切片。前端用File.prototype.slice把文件切成若干固定大小的块比如每片5MB或10MB后端按片接收最后再合并。第二步并发控制。切片只是开始如果你把100个切片一次性全部发出去浏览器和服务器都扛不住。这里需要做一个并发池控制同时上传的切片数量。我一般建议3~6个太少了浪费带宽太多了容易触发服务端连接数限制。伪代码大概是这样的async function uploadInConcurrency(file, chunkSize 5 * 1024 * 1024, concurrency 4) { const chunkCount Math.ceil(file.size / chunkSize); const queue []; const tasks []; for (let i 0; i chunkCount; i) { const chunk file.slice(i * chunkSize, (i 1) * chunkSize); const task async () { const formData new FormData(); formData.append(chunk, chunk); formData.append(index, i); formData.append(filename, file.name); // 这里补充你的上传请求 }; queue.push({ index: i, task }); } // 用并发池调度queue中的任务 const workers new Array(Math.min(concurrency, chunkCount)) .fill(0) .map(async () { while (queue.length) { const item queue.shift(); await item.task(); } }); await Promise.all(workers); }第三步断点续传和秒传。断点续传的关键是服务端要知道已有哪些分片。通常做法是上传前先向后端发一个校验请求带上filename和md5或者更快的计算方式比如抽样哈希后端返回已收到的分片索引列表前端跳过这些切片再传。秒传的原理也在这里——如果后端发现整个文件的哈希都已存在直接返回文件已存在前端弹个上传成功实际没有真正传。第四步失败重试和进度。单个切片失败后要支持重试而不是整个文件推倒重来。同时XMLHttpRequest的upload.onprogress或fetch的ReadableStream都能拿到整体进度前端应把进度除以切片完成数来显示百分比。面试加分点主动说出Web Worker可以承担文件切片的哈希计算把它引导向下一题这就顺理成章地展示了你的技术视野。2.2 Web Worker从计算哈希到任务池刚才提了大文件上传里的哈希计算——对大文件做全量MD5是很耗时的几十秒到几分钟都有可能。如果跑在主线程上页面直接卡死。这时候把hash计算塞进Web Worker界面保持流畅就是标准的懒人解法。但面试官不一定止步于此他可能继续问Web Worker里能操作DOM吗能跨域请求吗Dedicated Worker和Shared Worker有什么区别答案分别是一个都不能、可以、以及适用范围不同。Worker线程没有window和document不能碰DOM但可以用fetch发请求也能通过postMessage和主线程通信。关键是通信时数据是用结构化克隆structured clone序列化的不是引用传递——这也是面试中容易忽略的细节。我在实际项目里见过有人试图在Worker里直接修改一个大对象主线程里的值纹丝不动原因就在这。其实Worker在真实项目里的用途不只是处理大文件。我在给部门搭前端中台时用Worker维护了一套心跳上报池把页面内所有埋点消息先推到Worker线程统一调度再用navigator.sendBeacon发送。这样就算某个页面卡了埋点也不会丢。这类把通用任务下沉到Worker的思路比单纯背API更容易打动面试官。2.3 SSE与EventSource不是所有实时都要WebSocket实时通信题几乎每场面试都会出现。但2026年的新趋势是面试官会主动把你往非WebSocket方案上引因为很多前端工程师一谈实时就只知道WebSocket。SSEServer-Sent Events是考察的另一个方向。我用一个生活化的类比解释WebSocket像一对一的电话双方随时说话SSE更像广播电台服务端单向往客户端播客户端只需要竖起天线听。它底层走HTTP用text/event-stream这个MIME类型前端用EventSource接口接收const evtSource new EventSource(/api/events); evtSource.onmessage (event) { console.log(event.data); };SSE的价值在面试里怎么体现关键在于场景判断。比如聊天室、白板协作需要双向高频交互用WebSocket合理但像股票行情、AI对话流式输出、系统通知这类服务端主动推送、客户端被动接收的场景SSE就足够而且实现成本低得多——不需要单独维护一个长连接协议天然支持断线重连甚至能通过HTTP/2做多路复用。这里有一个我在追问中常踩到的坑面试官问SSE断线怎么办很多人答不上来。SSE的EventSource内置了断线重连但它重连时默认不携带上次的Last-Event-ID如果你不希望客户端重连后从头接收数据就得在后端配合回传这个ID客户端在onerror里重建连接时把它带上。这个细节一展开面试官对你的评价会完全不同。3. 业务层的架构追问字典管理、微前端和BPMN流程化的底层逻辑3.1 字典管理一个小功能背后的设计分水岭热搜词里出现了前端系统管理下的字典管理一般有啥用很多人觉得这只是个CRUD但面试官能从一个简单的字典管理问到你对前端状态设计的理解。字典是什么就是一组键值对比如性别{ male: 男, female: 女 }订单状态{ 1: 待支付, 2: 已支付, 3: 已取消 }。业务系统里大量下拉框、标签、状态回显都依赖字典。一个设计糟糕的前端字典管理是每个页面各自写死改一个状态名称要全局搜索替换。而好的设计有一套统一机制。第一层字典数据从哪来。通常由后端提供接口前端在登录后或首次进入系统时拉取缓存到全局状态如Pinia或Vuex。但只做到这里还不够你需要设计字典加载中/加载失败/数据缺失的兜底状态以及字典变更后的刷新策略。第二层字典怎么用。最经典的方式是封装一个useDict钩子或DictSelect /组件传入dictType它自动渲染下拉框。这背后的抽象逻辑是类型感知——前端代码里不直接写1、2、3而是通过映射表转成可读文案杜绝魔法数字。第三层字典与权限、国际化的混搭。如果你的系统需要多语言字典值可能也要做i18n如果某些字典项只有特定角色可见还要做权限过滤。把这些点聊透面试官就知道你不是只写过增删改查而是真的思考过配置驱动的架构设计。3.2 微前端的追问拆分粒度、通信方式和部署隔离微前端是2026年热搜里的常客前端面试必有一题。但现在的题不会再问什么是微前端而是给场景。最常见的是这样一个你们有多个团队负责一个大型中后台系统每个团队用不同的技术栈发布节奏也不同怎么落地微前端答题框架可以分三层拆分的边界原则。微前端的微不是指组件级而是应用级。通常用业务域做边界比如订单域、用户域、权限域每个域独立成一个子应用。最怕的是把组件级拆成微前端搞出几百个子应用麻烦远超收益。面试时可以突出这个别过度拆分的意识这是经验分。通信方案。不同子应用之间不能共享内存所以要靠全局事件总线、URL参数、自定义事件或localStorage来传数据。现在比较成熟的做法是主应用维护一个globalState子应用通过API订阅和修改。这里可以追问一句如何在子应用卸载时清理监听器避免内存泄漏——这是真正的加分细节。部署与集成。子应用通常是独立开发、独立部署构建产物交给主应用动态加载。你可以聊qiankun的registerMicroApps也可以聊module federation的联邦模块共享依赖。注意不是让你背它们各自的API而是要比较qiankun适合物理隔离生命周期管理强的场景module federation更适合依赖共享、构建期决策的场景。选型逻辑比工具本身更值钱。3.3 BPMN定制与OnlyOffice集成非典型场景里的思路调用热搜里有BPMN自定义流程和OnlyOffice部署这类需求多数前端工程师没做过但它恰恰是2026年业务流程数字化的缩影面试官会拿来做技术广度测试。BPMN题的核心在于你如何理解一个图形化流程设计器。通常用bpmn-js这个库。但如果面试官问要改造它实现自定义审批节点怎么办你需要答出两个层次。第一层先识别bpmn-js的模块化结构它内置了Modeler、Viewer、PropertiesPanel以及各种自定义element模板的机制。第二层自定义流程本质上是数据模型驱动渲染——你在moddle里扩展元素类型定义它的属性画布上的节点只是这些属性的可视化表达。把这个抽象关系讲明白说明你有驾驭复杂开源项目的能力。OnlyOffice集成题则更偏向你是否了解在线编辑的完整链路。一般会问前端怎么集成OnlyOffice文档服务器DocEditor初始化时传入哪些参数回调怎么处理权限怎么控制。你不需要真正跑通过代码但要回答出必须区分OnlyOffice Docs服务端和前端API两个部分、以及文档保存后的回调会向callbackUrl发POST请求这个机制。把这些关键链路说出来面试官就知道你有过调研。4. 那些搜索热度高但容易翻车的新方向4.1 WebCodecs与H264解码浏览器视频处理的新考点热搜里前端js解码h264讨论度很高可能是监控播放、视频编辑、音视频会议某个场景触发的。这道题为什么容易翻车因为很多前端对视频解码的认知停留在用video标签或给播放器传URL完全不清楚浏览器底层发生了什么。WebCodecs API是2026年面试官想听到的关键词。它让浏览器原生解码能力暴露给JS你可以拿到VideoDecoder的实例喂给它EncodedVideoChunk压缩的视频数据它通过回调输出VideoFrame解压后的帧。这有什么用在WebRTC、直播、视频编辑场景不再依赖复杂的播放器或video媒体流你可以直接对每一帧做处理——比如叠加水印、做滤镜、人脸识别。答题时建议按数据流来讲采集源摄像头/文件/WebSocket收到的流→ demux得到编码帧 → VideoDecoder解码 → VideoFrame绘制到Canvas/WebGL → 再经VideoEncoder编码 → 推流或保存。这个链路说完再补充一句WebCodecs是异步API注意控制队列积压、关注decodeQueueSize就能展现出你考虑过工程落地而不是停留在demo。顺便提一嘴面试官可能顺着问H.264和H.265有什么区别、码率控制怎么做。这里的本质是编码器的复杂度不同——H.265压缩率更高、但解码更耗时硬件兼容性要考虑。结合业务场景说明什么时候选265、什么时候选264比你死记硬背技术规格强得多。4.2 AI辅助编码时代面试开始考察人与工具的分工最近的热搜词出现了大量AI开发工具的讨论2026年面试的新题目可能直接变成你在项目里怎么用AI工具这道题背后考察的不是你会不会用Copilot而是你有没有形成AI辅助但不依赖的工作流。我的理解是面试官想听到三件事什么时候该让AI写代码什么时候该自己写。比如生成表单校验规则、写正则表达式、补单元测试这些都是模式匹配型任务交给AI效率高。但涉及核心业务状态流转、支付流程、权限校验这类领域敏感的代码最好不要直接信AI必须人肉审一遍。怎么向AI描述需求。一个优秀的prompt往往包含输入输出示例、边界条件、限制清单、验收标准。在面试里提到我会把接口文档片段丢给AI让它按公司规范生成Service层代码再人工review这比只会说用ChatGPT高级得多。如何验证AI产出的正确性。这是最大的分水岭。AI生成的代码没过测试、没有覆盖率、没有类型检查你敢直接上线吗一个成熟的工程师会把它丢进CI流水线让静态检查和单测来兜底。这个思路一定要表达出来。我也建议你在面试前准备一个AI提效的实例比如用AI快速把设计稿转成Vue组件但要讲清楚AI生成的代码踩了哪些坑——比如class命名混乱、样式侵入父组件、没有处理loading态。既有落地成果又有反思过程这种回答在面试中最能加分。4.3 前端性能与SEO从改标签到观测指标前端SEO这个问题在2026年再次翻热因为越来越多的SaaS产品和内容型站点开始重视前端可检索性。面试题目可能是你们项目SEO不好怎么排查从基础的讲robots.txt、sitemap.xml、meta标签、语义化HTML、SSR/SSG。但这套标签思维在面试里很可能被追问——如果项目已经上线不能大改怎么提升SEO这就考到动态渲染利用Puppeteer或rendertron检测到爬虫UA时就返回预渲染的HTML普通用户仍是SPA。这个方案能立刻提升收录率而且不用重构。性能优化题同理我不建议死背图片懒加载、代码分割、CDN缓存这些老话。2026年更好的答法是从指标反推方案。比如提到LCPLargest Contentful Paint太慢你先用Performance API拿到真实的LCP数据再判断瓶颈是网络加载还是脚本执行有针对性地做优化——资源预加载、压缩大图、删除阻塞渲染的JS每一步都对着指标说话。这个思路比背十条优化手段高级得多。4.4 表格标签与组件表格背后的工程取舍热搜里出现了前端表格标签和前端组件库。别觉得这题简单面试官可能拿它延伸出表格性能的经典追问表格里有10万条数据你怎么渲染 注意这题跟表格标签已经没关系了考的是你对虚拟滚动、分页、Web Worker计算的理解。所以把表格标签当引子你可以准备这样一条完整链路原生table语义化最好、SEO友好适合基础数据展示。组件表格如Element Plus的el-table封装了排序、筛选、分页、虚拟滚动适合中后台。但注意组件的虚拟滚动只针对视口可见范围如果表格内一个单元格里有大量DOM比如富文本或嵌套组件性能依然会崩。大数据网格如ag-Grid、TanStack Table适合复杂表格场景。答题时要能说出为什么不能直接用el-table 分页了事——因为有时候需求要求同一屏幕展示大量行且支持行内编辑只有开启行虚拟化和单元格级渲染才扛得住。5. 我最后想和你说点实在话本来聊到上面就可以收尾了但既然题目是面经我还是想多分享一点最近陪跑候选人时总结的体会。现在的面试越来越像技术合伙人面试而非工程师招聘面试。面试官希望看到你像一个技术方案的owner而不是一个任务的executor。所以你在准备时可以把自己做过的每个项目都过一遍为什么、选型取舍、如果重来会改什么这三问。很多人忽略的另一个细节是诚实边界。技术面里最忌讳的不是答错而是不懂装懂。我见过一个候选人被追问到Worker线程池的细节时坦诚说这里我确实没在真实项目里用过只做过Demo面试官反而继续友好地引导另一个候选人不懂装懂被追问两轮之后露馅整场印象分直接崩掉。所以面对没把握的问题你可以正面回答我理解的是……但我没实际验证过比硬撑着强。最后不要把面经当成题库把它当成查漏补缺的清单。你打开这篇文章看到大文件上传、SSE断线重连、微前端通信这些点如果每一个都能不卡壳地讲出设计思路 踩坑经历 可落地的代码结构那你大概率已经通关了。如果哪一节让你觉得哦原来这里还有一层那就花一两个周末把它做一个小的Demo跑一遍。面试前用这种最小可验证的方式查漏比刷十道大厂真题更管用。祝你能把面试当成一场技术对话聊出自己的底气。