上周刚面完爱奇艺前端二面趁着记忆还热乎赶紧把过程整理出来。这一面整整聊了80分钟面试官全程没有问任何框架API背诵题所有问题都围绕实际场景展开从项目细节一路追到底层原理有好几道题我都是边思考边回答复盘的时候发现踩了不少坑。这篇文章我会把自己被问到的问题、当时的回答思路、以及面试官追问的深度的完整记录下来同时附上我回顾总结后的正确答案和思考过程希望能给准备大厂前端面试的朋友一些参考。1. 面试前的准备思路1.1 针对爱奇艺业务特点做功课面爱奇艺之前我特意去研究了一下他们的前端技术栈和业务场景。爱奇艺的前端主要分为几条线主站PC/H5、移动端App内嵌页、以及视频播放相关的复杂业务。视频网站的前端和普通业务系统最大的区别在于性能优化是重中之重首屏时间直接影响用户留存播放器相关的交互复杂度极高同时因为用户量大任何页面的渲染性能问题都会被放大到很严重的程度。我当时梳理了几个必考的方向视频首屏优化方案、大列表渲染性能、前端缓存策略、以及跨端适配问题。后来回看这些方向确实都覆盖到了。另外我还特意准备了一个自己做过的高难度项目把技术选型原因、遇到的核心问题、解决方案的演进过程都梳理了一遍。大厂二面非常喜欢深挖项目尤其是你提到的任何技术点面试官都可能顺着往下追所以准备项目时一定要把每个细节都吃透。1.2 把基础知识过成面试逻辑说实话我之前也背过八股文但后来发现真正有效的准备方式是把每个知识点整理成“场景-问题-解决方案-原理”的结构而不是死记硬背概念。比如问CSS性能优化我会先说在什么场景下会遇到样式卡顿再分析原因重排重绘、选择器性能、图层合成等最后给出优化手段和原理依据。这样准备的好处是面试官不管从哪个角度追问你都有话可说。爱奇艺二面那天我明显感觉到面试官问问题的方式是层层递进的他会先问一个基础概念然后不断加大深度看你的知识边界在哪里所以千万不要只背结论一定要逼自己理解背后的原理。2. 项目深挖环节简历上每一个字都要经得起追问2.1 第一个项目视频后台管理系统面试官一开始就让我挑一个认为最有代表性的项目详细讲我选了之前做过的视频后台管理系统。这个系统主要负责视频上传、转码状态跟踪、内容审核和发布管理数据量级在百万级视频条目操作频率很高。我介绍了整体架构采用Vue3 TypeScript Pinia Element Plus使用Vite作为构建工具后端接口走的是RESTful API。面试官听完后第一句话就问“你们为什么用Vue3而不是Vue2有没有对比过两个版本在你们这个项目上的具体差异”这个问题看起来简单但用心险恶。如果只回答“Vue3性能更好、Composition API更灵活”这种泛泛之谈肯定不够。我当时的回答是一是项目规模中等需要更好的类型推导和逻辑复用能力Composition API可以按业务维度组织代码而不是按选项类型分散二是Vue3的响应式系统基于Proxy在深层响应式数据上不会有Vue2中新增属性丢失响应式的问题三是我们实际测过在相同的数据量级下Vue3的渲染更新性能大约提升20%到30%。面试官对这个回答点了点头但紧接着就开启了追问模式。他问的第二个问题是“Pinia和Vuex你是怎么取舍的”这个问题我是有准备的Pinia的API更简洁、天然支持TypeScript、没有mutation的概念、模块化不需要命名空间嵌套。但面试官追问了一句“Pinia的响应式原理是什么”说实话这里我差点卡壳。我当时的回答是把Pinia底层的state通过reactive或ref包装成响应式对象借助Vue的依赖收集机制实现状态追踪。2.2 面试官深挖上传功能的技术细节然后面试官问我视频上传功能是怎么做的这部分他又抛出了一个经典场景题“如果用户上传过程中断网了怎么保证上传的可靠性”我提到用的是分片上传方案将大文件切成多个分片每片2MB前端逐个上传后端返回每个分片的存储标识全部上传完成后前端发送合并请求后端将分片拼接成完整文件。断点续传的实现是上传前先从后端查询该文件已经上传了哪些分片然后只传缺失的部分。为了保证文件在切分前后的完整性前端用文件的MD5哈希值作为唯一标识合并后校验哈希不一致则重新上传。面试官追问“分片大小你是怎么确定的如果让你选2MB和8MB哪个更好为什么”这个问题我事先没准备得太细当场想了一下才回答。分片大小的选择取决于网络环境和失败重试成本分片越小失败后重试的数据量越小但分片数量多每个分片都需要额外的请求头部和校验信息整体请求开销增大分片越大请求次数少但一旦失败重传成本高而且大文件在HTTP传输中更容易因为网络波动导致中断。我们还测过在普通办公网环境下2MB比较合适在移动网络环境下可能需要调整到1MB甚至更小。面试官追了一句“如果目标用户是弱网环境你会怎么动态调整分片大小”我的思路是根据当前网络状态navigator.connection.effectiveType做一个自适应策略4G环境用2MB分片3G环境降为512KB同时实现失败重试的退避算法。这算是临时想出来的方案面试官没有再深入但也没有否定。2.3 项目中的性能优化实战接下来面试官问了项目里最有成就感的一个优化点我讲到列表页的渲染优化。视频管理列表单页需要展示上千条数据包括封面图、标题、状态标签、操作按钮等早期直接渲染DOM节点导致页面卡顿滚动有明显的掉帧。我采用的方案是虚拟列表只渲染可视区域内的DOM节点滚动时通过计算startIndex和endIndex动态更新渲染列表。具体实现思路是外层容器设置固定高度并监听scroll事件inner container高度设为总列表高度——这样滚动条才会正常然后对可视区域内的item做绝对定位滚动时重新计算每个item的top值。面试官听完之后问“你自己实现虚拟列表有没有遇到过边界问题”他这句话直接戳中了我踩过的坑。我说有两个比较棘手的点一是快速滚动时会看到空白闪烁解决办法是在可视区域上下各加一个buffer区多渲染一部分数据来覆盖滚动间隙二是动态高度的item处理难度很大如果每条数据的高度不固定需要在内容渲染后测量实际高度并维护一个位置缓存测量本身又可能引发二次渲染所以初期我们直接统一了封面图的尺寸规避了动态高度问题。面试官追问“如果产品要求动态高度你会怎么设计”我回答可以维护一个高度缓存池配合ResizeObserver监听元素尺寸变化滚动时用二分查找快速定位当前的起始位置。这个环节给我最大的感受是面试官不会只问你做了什么东西他更关心你踩过什么坑、怎么解决的、如果换一种情况你怎么应对。能体现思考深度的回答才是加分项。3. 前端基础与原理考察八股文面试的进阶版3.1 浏览器渲染原理从输入URL到页面展示项目深挖完之后面试官话锋一转问了一道看起来非常基础但实际考察深度的问题“从输入URL到页面渲染完成这个过程中浏览器做了哪些事情”我把完整流程过了一遍DNS解析域名拿到IP建立TCP连接如果协议是HTTPS还需要TLS握手发送HTTP请求服务端返回HTMLHTML解析构建DOM树同时CSS解析构建CSSOM树两者合并生成渲染树Render Tree然后进入布局Layout阶段计算每个节点的几何位置最后进入绘制Paint阶段再通过合成Composite把图层输出到屏幕。面试官没让我背完就直接打断问了一个细节“CSSOM构建过程中如果遇到CSS文件是阻塞的吗JS文件的执行阻塞DOM解析吗async和defer的区别是什么”我回答CSS是阻塞渲染的——浏览器要等CSSOM构建完成才会开始渲染页面因为如果没有样式信息渲染出来的页面会闪一下无样式内容FOUCJS默认是阻塞解析的因为JS可能通过document.write修改DOM结构所以浏览器遇到script标签会停下来等脚本下载并执行完再继续解析DOM。async和defer都可以实现异步加载脚本区别在于执行时机defer是在文档解析完成后、DOMContentLoaded之前按顺序执行async是脚本下载完成后立即执行执行顺序不保证。面试官追问了句“有没有什么方式可以突破JS文件的加载阻塞”我给出了几个方向使用script标签的async/defer属性关键脚本内联到HTML中避免额外请求非关键脚本可以放在body末尾或通过动态加载的方式延迟执行。3.2 事件循环与异步编程宏任务和微任务面试官说“来写一段代码告诉我输出顺序”然后在白板上写了这道题console.log(script start) setTimeout(() { console.log(setTimeout 1) }, 0) Promise.resolve() .then(() { console.log(promise 1) }) .then(() { console.log(promise 2) }) queueMicrotask(() { console.log(queueMicrotask) }) console.log(script end)这道题考的是事件循环机制同步任务先执行所以先输出script start和script end然后执行微任务队列Promise和queueMicrotask都会进入微任务队列按注册顺序执行所以依次是promise 1、queueMicrotask、promise 2。注意这里promise 1执行完之后返回一个新Promise这个新Promise的then回调会追加到微任务队列末尾所以在queueMicrotask之后执行。全部微任务清空后再去宏任务队列取setTimeout执行输出setTimeout 1。面试官看我答完又追问了一个变体“如果setTimeout延迟是0是不是会立即执行”我说不会即使延迟为0浏览器也有一个最小延迟时间一般是4ms而且必须等当前任务队列和微任务队列都清空之后才会轮到宏任务执行。这也是为什么setTimeout回调里修改DOM会比Promise的微任务更晚生效。我觉得大厂面试考察事件循环重点不是背结论而是看你能不能讲清楚执行顺序背后的调度规则。每次答这种题在脑海里过一遍“当前调用栈是否为空、微任务队列是否为空”这两个判断条件顺序就不会乱。3.3 作用域与闭包从现象到原理面试官在代码题环节又抛了一道闭包相关的问题for (var i 0; i 5; i) { setTimeout(() { console.log(i) }, 100) }这个输出结果应该是5个5因为var声明的i是函数作用域循环结束后i已经是5五个定时器回调共享同一个i。面试官问怎么改成输出0到4我给出了三种方案把var改成let利用块级作用域每次循环产生新的绑定用IIFE立即执行函数传入当前i的值或者用bind方法绑定参数setTimeout(console.log.bind(null, i), 100)。面试官接着问我“闭包的本质是什么”。我当时的回答是闭包是函数和它声明时所在词法作用域的组合。JavaScript的函数在被定义时会保存一个隐藏属性[[Environment]]指向创建时的外部词法环境。当函数在其他地方被调用时引擎会通过这个属性找回原始作用域链把外部变量保留下来这就是闭包产生的原理。函数能够记住并访问它的词法作用域即使这个函数是在当前作用域之外执行的也是从引擎层面的作用域链实现来讲闭包为什么能访问外部变量。追问来了“闭包会带来内存问题吗怎么排查”我说如果闭包引用了外部大对象而这个闭包本身又被长期持有的引用指向正常GC就无法回收这些外部变量可能造成内存泄漏。排查手段主要是用Chrome DevTools的Memory面板做堆快照对比定位到持有大量不释放内存的对象以及用performance面板录制看内存曲线是否持续上涨。使用上需要注意事件监听器用完要解绑定时器要清掉避免把大对象catch进闭包里不需要的生命周期里。3.4 CSS性能与布局一个被低估的考察点面试官突然问了一个我准备时没有重点考虑的知识点“CSS动画和JavaScript动画相比性能上有什么区别为什么CSS动画在某些情况下更好”这个问题我稍微想了一下才回答。CSS动画和JS动画的核心区别在于CSS动画如果只操作transform和opacity可以绕过布局和绘制阶段直接在合成器compositor线程上执行不占用主线程而JS动画通常要操作DOM的几何属性top、left每次变化都触发主线程的布局计算和重绘。所以CSS动画的关键在于把动画限制在合成器可以处理的属性上transform做位移、旋转、缩放opacity做透明度变化。为了触发GPU加速还可以加上will-change: transform或者translateZ(0)但不要滥用因为每个合成层都会占用GPU内存。面试官接着追问“Chrome渲染一帧的流程是什么什么情况下会丢帧”这里其实是在考渲染流水线和帧预算的概念。我回答浏览器每16.6ms生成一帧帧的生成需要经过JS执行、样式计算、布局、绘制、合成等步骤。如果在主线程上执行的任务超过了16.6ms浏览器就无法按时产生下一帧表现出来就是掉帧卡顿。常见的丢帧原因包括JS长任务阻塞主线程、频繁的布局抖动强制同步布局、绘制面积过大、合成层过多导致内存压力过高。优化的核心思路是减少主线程工作量——长任务拆分成小任务避免强制同步布局先读后写原则把可以放合成器的操作尽量放合成器。4. 工程化与架构设计考察前端广度与体系化思考4.1 Webpack构建优化实战工程化这部分问的也比较深面试官问的是“你们的项目是用Webpack还是Vite如果让你对Webpack做个构建优化你会从哪些维度下手”我说了我们早期项目是Webpack后来新项目切了Vite所以两个都要会讲。Webpack构建优化的核心是压缩构建时间维度时间和产物体积维度体积。时间优化方面用thread-loader开启多进程Loader解析用cache-loader或者Webpack5内置的filesystem cache缓存模块编译结果用DLL或hard-source-webpack-plugin做更细粒度的缓存配置resolve.alias减少模块查找范围resolve.extensions减少无谓的文件探测。体积优化方面代码压缩用terser-webpack-pluginJS和css-minimizer-webpack-pluginCSS开启gzip或brotli压缩用splitChunks把公共依赖抽出成单独chunk避免重复打包动态import做路由级代码分割配合preload/prefetch做预加载用webpack-bundle-analyzer分析产物体积。面试官进一步问道“你们是怎么做路由级代码分割的”我说通常是webpack的魔法注释结合动态importconst Home () import(/* webpackChunkName: home */ views/Home.vue)这样每个路由页面会成为独立的chunk只有访问该路由时才会加载对应JS。面试官追问首屏会有什么影响我答首屏需要的JS更少解析执行时间更短启动更快但代价是切换路由时多了一个网络请求的延迟所以需要配合prefetch预加载策略让浏览器在空闲时间段把其他路由的chunk提前下载下来。还有一种是preload策略只针对首屏接下来一定会用到的资源来加载优先级更高。4.2 微前端架构为什么要拆怎么拆聊着聊着面试官突然问了一句“你们有了解过微前端吗如果你们团队要把多个独立系统整合到一个平台上你会怎么设计”这个题问得比较宽我理解他想考的是系统设计能力和对微前端本质的理解。我回答了几层微前端解决了多个团队、多套技术栈、独立部署的子系统需要整合到一个主应用中的问题。它本质上是一种比组件复用更粗粒度的应用拆分与组合机制。常见的实现方案有qiankun基于single-spa的封装支持JS沙箱和样式隔离、无界WebComponent iframe方案、Module FederationWebpack5提供的能力实现运行时共享依赖和代码。面试官追问“你刚才提到JS沙箱它的原理是什么”我说JS沙箱的核心目标是隔离子应用的全局作用域避免子应用之间、子应用与主应用之间的全局变量互相污染。qiankun的实现思路是在激活子应用时对window上新增的属性做快照记录子应用卸载时恢复这些快照还有一种基于Proxy的方案就不用遍历快照而是创建一个代理的window对象每个子应用操作window属性时实际读写的是自己的一份独立代理对象。样式隔离是靠严格约定 CSS前缀或者给子应用容器的选择器加上前缀使样式只对子应用内部生效以及shadow DOM方案。4.3 Node层与全栈能力中间层能解决什么问题面试官问“前端有没有可能涉及Node层你是怎么理解BFFBackend For Frontend的”这题我觉得他是想考察你对前后端协作模式的理解而不单纯是问你会不会写Node。我觉得我在团队里的项目就实践过BFF我们有一个视频推荐页需要同时聚合用户信息接口、视频元数据接口、推荐算法接口三个后端服务的数据。如果让浏览器直接调这三个接口一是请求数太多二是每个接口返回的数据结构和页面需要的结构差异很大前端要做大量适配三是有些接口只给部分用户开放浏览器直连可能会暴露不必要的后端逻辑。所以我们在Node层加了一个聚合网关浏览器只发一次请求Node层并发去调三个后端接口把数据组装成前端需要的结构一次返回。Node层的价值可以概括为聚合请求减少网络往返、数据格式转换适配前端、隐藏后端敏感信息、可以做服务端渲染和模板注入。面试官点了点头又问“你在Node层遇到性能瓶颈怎么办”我说Node是单线程事件循环模型CPU密集型任务会阻塞事件循环。处理思路有把需要大量计算的逻辑拆分出去用worker_threads子线程执行或者把计算任务下沉到独立的服务避免影响I/O型的接口响应。做服务端渲染时尤其要注意复杂度平衡不要为了首屏快而给服务器增加过大的渲染压力必要的时候可以加缓存或者做流式渲染。5. 代码题与场景题实战手写实现考察代码能力5.1 手写实现一个深拷贝函数面试官直接说“写一个深拷贝函数要求支持基本类型、数组、普通对象、函数、Date、RegExp同时要考虑循环引用。”这道题我比较熟核心思路是递归 WeakMap保存引用关系遇到循环引用时直接返回已经创建的对象。我当时的现场实现大致是function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) { return target } if (map.has(target)) { return map.get(target) } if (target instanceof Date) { return new Date(target.getTime()) } if (target instanceof RegExp) { return new RegExp(target.source, target.flags) } if (target instanceof Map) { const cloneMap new Map() map.set(target, cloneMap) for (const [key, value] of target) { cloneMap.set(deepClone(key, map), deepClone(value, map)) } return cloneMap } if (target instanceof Set) { const cloneSet new Set() map.set(target, cloneSet) for (const value of target) { cloneSet.add(deepClone(value, map)) } return cloneSet } const cloneTarget Array.isArray(target) ? [] : {} map.set(target, cloneTarget) for (const key of Reflect.ownKeys(target)) { const desc Object.getOwnPropertyDescriptor(target, key) if (desc value in desc) { cloneTarget[key] deepClone(target[key], map) } } return cloneTarget }面试官看完代码追问了两个细节一个是“为什么要用WeakMap而不是普通Map”我说WeakMap的key是弱引用不阻止垃圾回收。当原始对象不再被引用时映射表中的记录可以被GC回收掉不会造成内存泄漏深拷贝创建的对象和原始对象生命周期一致所以用WeakMap更合适。一个是“Reflect.ownKeys和Object.keys的区别在哪”我说Object.keys只返回可枚举的自有字符串属性Reflect.ownKeys返回所有自有属性键包括Symbol和不可枚举的属性所以在拷贝时能把这些特殊属性的情况也覆盖到不过实际用的时候也要考虑是否需要拷贝不可枚举属性。5.2 手写函数防抖和节流“实现一个防抖函数和一个节流函数并说明它们各自的使用场景。”这题算是前端面试高频中的高频了。我的实现是function debounce(func, delay 300) { let timer null return function (...args) { clearTimeout(timer) timer setTimeout(() { func.apply(this, args) }, delay) } } function throttle(func, interval 300) { let lastTime 0 return function (...args) { const now Date.now() if (now - lastTime interval) { lastTime now func.apply(this, args) } } }面试官问“如果防抖函数的调用非常频繁delay时间内一直有事件触发回调是不是一直不会执行有没有办法让它在等待过程中也执行一次”我回答可以用“立即执行版本”防抖第一次触发立即执行func后续在delay时间内触发都取消等延迟结束之后再触发才会重新立即执行。实现上是在防抖函数里维护一个immediate标志变量。5.3 场景题大列表渲染方案设计面试官出一个综合性场景题“假设页面上有一个非常大的列表可能好几万条数据每条数据渲染耗时较高。请你设计一个方案让用户在滚动时保持流畅。”这个问题他其实想看我综合运用虚拟列表、时间分片、requestIdleCallback这些方案的能力。回答思路分了三个层面数据层面如果数据不需要全部展示只保留当前可视区域和缓冲区的数据其他的都截断丢弃渲染层面用虚拟列表只渲染可视DOM滚动时更新计算起始结束索引并建议在列表项上做稳定key和样式复用避免频繁创建销毁计算层面如果每一条数据的渲染本身很重比如需要做复杂计算可以借助requestIdleCallback把非紧急的计算任务拆分成时间片处理确保每帧都有空余时间再执行计算任务避免阻塞主线程。面试官又问“如果列表项内部还有图片且图片是懒加载的你怎么做”我说图片懒加载用IntersectionObserver监听图片进入视口时再设置src加载同时给外层容器指定占位尺寸避免列表滚动时布局抖动。需要注意虚拟列表滚动过程中不断创建弹出新DOM节点图片懒加载的触发时机要卡在缓冲区内就提前触发否则用户看到图片区域会有明显的白屏等待。这一轮回答完我感觉面试官比较满意因为他开始把问题重心转向了下一方向“你既然提到了性能优化那爱奇艺这种视频网站你觉得首屏优化怎么做更有效”6. 视频场景下的前端性能优化专项6.1 视频网站首屏加载优化这个问题我其实准备了很多毕竟面试的是爱奇艺视频场景肯定绕不开。我从资源加载、渲染、交互三个维度展开说资源加载方面首屏所需的JS按路由拆包尽量控制初始包体用preload提前加载首屏模块依赖用prefetch预加载其他页面路由静态资源上CDN gzip/brotli图片和视频封面用WebP/AVIF格式超过一定尺寸做压缩和裁切。渲染方面骨架屏先用静态HTML或CSS模拟页面结构让用户感觉页面加载很快真实数据到了再替换用服务端渲染或者静态生成减少白屏时间如果没条件上SSR至少保证首屏用的数据在HTML中直接内置首屏直出避免先请求JS再请求数据的串行等待。交互方面关键操作要提前绑定事件首屏大图用loadinglazy延迟非首屏图片上拉加载更多用IntersectionObserver而不是在scroll事件里做高度计算。面试官追问了一个特别细的问题“视频首屏封面图和标题是后端直接下发还是前端获取的”我意识到他想考察的是数据流设计就回答理论上应该由后端直接下发首屏渲染需要的初始化数据也就是第一次HTML请求时把这些数据内联到页面前端不需要二次请求能省一次网络往返。如果能拿到包含封面图地址和标题的基础数据就能快速铺满首屏。6.2 Web Worker在前端的应用场景面试官问“如果页面里有一段很耗时的数据处理逻辑比如对一个大数组做排序或加密直接执行会导致页面卡顿。你有哪些解决方案”我提到了Web Worker方案把耗时任务放到独立的Worker线程里运行主线程只负责接收结果和更新UI。在视频场景下可以把视频数据的分片Hash计算、加解密、大数据量的格式处理等放到Worker里。我还提到最近有一个新趋势是OffscreenCanvas可以把Canvas的绘制操作也放到Worker线程执行主线程只保留最终显示用的画布合成这对复杂视觉效果的渲染优化很有帮助。之前我在项目里用Worker上传大文件的思路是把文件分片后在Worker里计算每个分片的MD5避免阻塞主线程去做哈希计算计算完成后返回给主线程再逐个上传。后来看热词里也包括“前端使用worker上传大文件”说明这确实是热门且被很多团队验证过的方案。如果需要降低计算成本可以考虑用web worker中直接跑hash.js或SparkMD5这类库注意控制每个分片的大小和并发策略避免把Worker线程也压满。面试官还问了一个很实际的问题“Worker之间通信的开销会不会反而成为性能瓶颈”我回答PostMessage的类型是结构化克隆它会把数据复制一份传输大数据时复制成本不可忽略。所以不要把大块数据反复通过postMessage发送最好是只传计算参数和最终结果。如果一定要共享大量数据可以考虑使用SharedArrayBuffer但要注意跨线程竞争的同步问题这个方案浏览器支持情况和潜在的安全限制需要慎重评估。6.3 播放器相关H264解码与视频播放渲染面试官问了一个偏场景的问题“做视频播放器时前端解码H264视频流并在Canvas上播放你会怎么做会遇到哪些问题”这个问题说实话我不算最有把握因为我不是专门的播放器开发但我尽量分析了技术方案。前端解码H264可以用WebAssembly方案用ffmpeg编译成wasm在浏览器里实现软解。如果追求性能可以走WebCodecs API浏览器原生提供视频编码解码能力通过VideoDecoder接口解码H264帧然后把解码后的VideoFrame绘制到Canvas上或者直接交给Video元素渲染。WebCodecs的方案性能好很多因为底层走的是硬件解码通道。潜在的问题包括浏览器兼容性差异、SEI信息处理用于音视频同步、关键帧缺失时首帧解码时间长、内存占用控制解码后的原始帧数据量很大需要及时释放资源。面试官听我说到内存占用追了一句“Canvas上播放视频会一直累积内存吗”我回答如果不显式关闭已解码的VideoFrame或释放对应的Canvas缓冲区确实可能会造成内存持续增长。正确做法是每次绘制完成之后调用frame.close()释放资源。控制解码队列长度不要让解码器无限压入帧数据用背压机制等待渲染完成再解码下一帧。这轮视频专项我觉得面试官应该是有业务背景的问的问题都特别贴近实际业务场景。我也如实说了自己不是播放器方向的专业开发面试官表示理解然后顺势切到了最后一个反问环节。7. 反问环节向面试官提问的正确姿势二面最后面试官问“你有什么想问我的吗”这个环节很多人不重视但我觉得面试官其实在乎的是你有没有真正思考过这个团队和业务方向。我问了三个问题第一个是“爱奇艺前端团队目前的技术栈是什么有没有在推Vue3/React新版本或者新构建工具”他说主站偏Vue技术栈但团队也在尝试新的方向。第二个是“视频业务的前端性能优化你们团队内部有没有一套成体系的监控指标和预算机制新人对这套体系的理解是否有机会深入”这个问题的潜台词是我希望加入的团队是真正把性能当工程来做的而不是只在出了问题才排查。第三个问题是“如果我能通过面试团队当前最大的技术挑战是什么”这个问题能让面试官聊他关心的事拉近距离。可能也是因为反问环节我比较认真面试官最后说“今天聊得挺充分后面流程会有hr跟进”我当时就感觉聊得还不错。面完之后再回头看反问环节的问题本身比答案更重要好的提问能展示你的思考深度和职业成熟度。8. 复盘与总结爱奇艺前端二面的几个核心经验8.1 从这次面试看大厂前端的考察重点从爱奇艺二面的整体节奏来看我觉得大厂前端面试已经不太满足于背八股文了。面试官更像是在做一个“能力画像”的绘画先通过项目深挖了解你实际做过什么、踩过什么坑、有没有思考沉淀然后通过基础原理题检验你的知识是不是成体系能不能层层深入再通过场景设计和代码题考察你把知识落到实际业务的能力。面试过程中我最明显的感受是面试官会把每个回答当成对话的起点而不是终点。你说到一个技术点他会立刻追问下一个层级看你有没有想过更深层的边界和取舍。比如虚拟列表的buffer区、Worker通信开销、深拷贝的WeakMap选择这些问题不会在常规八股文里出现但他们考察的都是你“有没有真正写代码思考过”。8.2 我踩过的几个坑希望你能避开第一个坑项目介绍太空泛。这次面试我一开始介绍项目时讲了很多“我们用了什么技术栈”这类信息面试官没怎么追但后续问题一深入就暴露了一些细节不够扎实。正确做法是介绍项目时直接说“我在这个项目里承担什么角色、解决了什么核心问题、取得的量化的结果是什么”把技术选型的过程放到后续的回答里穿插。第二个坑原理类问题准备不足。比如Pinia响应式原理、微前端沙箱原理这种问题只看过文档没看源码的话很容易车轱辘话来回说。如果你的简历上写了“熟悉xx框架原理”就一定要去源码层面把核心机制搞明白否则面试官一追问就会露怯。第三个坑场景题回答太单一。面试官问大列表优化如果你只说“用虚拟列表”就结束了基本等于放弃了这个题。更好的方式是从多个维度展开数据层怎么处理、渲染层怎么处理、计算层怎么处理、交互层怎么处理分析每个方案的取舍和适用场景。8.3 针对后续面试的复习建议我在准备下一轮面试时给自己列了一个更具体的复习清单这次也分享出来性能优化不能只背纯概念要落到关键指标FCP、LCP、CLS、INP上理解它们各自的测量原理和影响因子知道优化手段对应的指标提升关系。框架源码阅读以“核心响应式原理”和“渲染更新流程”为突破口Vue3重点读effect、reactive、ref、renderer这部分React重点看fiber调度和hook的实现机制。手写题不要只记实现要把设计思考和边界条件也讲清楚比如深拷贝怎么处理循环引用、防抖的立即执行版本、Promise.allSettled等。多给自己出开放场景题比如“实时协作编辑器”“大文件上传”“直播弹幕系统”这类典型高复杂度场景练习多角度分析问题的能力。对视频领域特有的问题要有所准备视频切片策略、首帧优化、解码渲染方案、直播延迟优化等面试视频业务团队这些都是高频方向。这次爱奇艺二面给我的整体感觉是考察很立体、问得很细面试官经验丰富对前端技术有很深的理解和热情。虽然中间有几个瞬间我回答得不够自信但整体来看能用经验加临场推理撑住大部分问题。面完当天晚上我自己把面试过程中所有没答好的点重新整理了一遍后面再遇到类似的问题就不会慌了。最后再分享一个很有用的备战技巧面试前把自己的项目经历和核心技术点全部写成一条一条的“面试官可能的追问树”每个主知识点向下展开至少三层追问然后逐个写清楚答案。提前做这个训练面试时即使遇到没准备过的角度也能快速组织逻辑而不是头脑空白。
上周刚面完爱奇艺前端二面趁着记忆还热乎赶紧把过程整理出来。这一面整整聊了80分钟面试官全程没有问任何框架API背诵题所有问题都围绕实际场景展开从项目细节一路追到底层原理有好几道题我都是边思考边回答复盘的时候发现踩了不少坑。这篇文章我会把自己被问到的问题、当时的回答思路、以及面试官追问的深度的完整记录下来同时附上我回顾总结后的正确答案和思考过程希望能给准备大厂前端面试的朋友一些参考。1. 面试前的准备思路1.1 针对爱奇艺业务特点做功课面爱奇艺之前我特意去研究了一下他们的前端技术栈和业务场景。爱奇艺的前端主要分为几条线主站PC/H5、移动端App内嵌页、以及视频播放相关的复杂业务。视频网站的前端和普通业务系统最大的区别在于性能优化是重中之重首屏时间直接影响用户留存播放器相关的交互复杂度极高同时因为用户量大任何页面的渲染性能问题都会被放大到很严重的程度。我当时梳理了几个必考的方向视频首屏优化方案、大列表渲染性能、前端缓存策略、以及跨端适配问题。后来回看这些方向确实都覆盖到了。另外我还特意准备了一个自己做过的高难度项目把技术选型原因、遇到的核心问题、解决方案的演进过程都梳理了一遍。大厂二面非常喜欢深挖项目尤其是你提到的任何技术点面试官都可能顺着往下追所以准备项目时一定要把每个细节都吃透。1.2 把基础知识过成面试逻辑说实话我之前也背过八股文但后来发现真正有效的准备方式是把每个知识点整理成“场景-问题-解决方案-原理”的结构而不是死记硬背概念。比如问CSS性能优化我会先说在什么场景下会遇到样式卡顿再分析原因重排重绘、选择器性能、图层合成等最后给出优化手段和原理依据。这样准备的好处是面试官不管从哪个角度追问你都有话可说。爱奇艺二面那天我明显感觉到面试官问问题的方式是层层递进的他会先问一个基础概念然后不断加大深度看你的知识边界在哪里所以千万不要只背结论一定要逼自己理解背后的原理。2. 项目深挖环节简历上每一个字都要经得起追问2.1 第一个项目视频后台管理系统面试官一开始就让我挑一个认为最有代表性的项目详细讲我选了之前做过的视频后台管理系统。这个系统主要负责视频上传、转码状态跟踪、内容审核和发布管理数据量级在百万级视频条目操作频率很高。我介绍了整体架构采用Vue3 TypeScript Pinia Element Plus使用Vite作为构建工具后端接口走的是RESTful API。面试官听完后第一句话就问“你们为什么用Vue3而不是Vue2有没有对比过两个版本在你们这个项目上的具体差异”这个问题看起来简单但用心险恶。如果只回答“Vue3性能更好、Composition API更灵活”这种泛泛之谈肯定不够。我当时的回答是一是项目规模中等需要更好的类型推导和逻辑复用能力Composition API可以按业务维度组织代码而不是按选项类型分散二是Vue3的响应式系统基于Proxy在深层响应式数据上不会有Vue2中新增属性丢失响应式的问题三是我们实际测过在相同的数据量级下Vue3的渲染更新性能大约提升20%到30%。面试官对这个回答点了点头但紧接着就开启了追问模式。他问的第二个问题是“Pinia和Vuex你是怎么取舍的”这个问题我是有准备的Pinia的API更简洁、天然支持TypeScript、没有mutation的概念、模块化不需要命名空间嵌套。但面试官追问了一句“Pinia的响应式原理是什么”说实话这里我差点卡壳。我当时的回答是把Pinia底层的state通过reactive或ref包装成响应式对象借助Vue的依赖收集机制实现状态追踪。2.2 面试官深挖上传功能的技术细节然后面试官问我视频上传功能是怎么做的这部分他又抛出了一个经典场景题“如果用户上传过程中断网了怎么保证上传的可靠性”我提到用的是分片上传方案将大文件切成多个分片每片2MB前端逐个上传后端返回每个分片的存储标识全部上传完成后前端发送合并请求后端将分片拼接成完整文件。断点续传的实现是上传前先从后端查询该文件已经上传了哪些分片然后只传缺失的部分。为了保证文件在切分前后的完整性前端用文件的MD5哈希值作为唯一标识合并后校验哈希不一致则重新上传。面试官追问“分片大小你是怎么确定的如果让你选2MB和8MB哪个更好为什么”这个问题我事先没准备得太细当场想了一下才回答。分片大小的选择取决于网络环境和失败重试成本分片越小失败后重试的数据量越小但分片数量多每个分片都需要额外的请求头部和校验信息整体请求开销增大分片越大请求次数少但一旦失败重传成本高而且大文件在HTTP传输中更容易因为网络波动导致中断。我们还测过在普通办公网环境下2MB比较合适在移动网络环境下可能需要调整到1MB甚至更小。面试官追了一句“如果目标用户是弱网环境你会怎么动态调整分片大小”我的思路是根据当前网络状态navigator.connection.effectiveType做一个自适应策略4G环境用2MB分片3G环境降为512KB同时实现失败重试的退避算法。这算是临时想出来的方案面试官没有再深入但也没有否定。2.3 项目中的性能优化实战接下来面试官问了项目里最有成就感的一个优化点我讲到列表页的渲染优化。视频管理列表单页需要展示上千条数据包括封面图、标题、状态标签、操作按钮等早期直接渲染DOM节点导致页面卡顿滚动有明显的掉帧。我采用的方案是虚拟列表只渲染可视区域内的DOM节点滚动时通过计算startIndex和endIndex动态更新渲染列表。具体实现思路是外层容器设置固定高度并监听scroll事件inner container高度设为总列表高度——这样滚动条才会正常然后对可视区域内的item做绝对定位滚动时重新计算每个item的top值。面试官听完之后问“你自己实现虚拟列表有没有遇到过边界问题”他这句话直接戳中了我踩过的坑。我说有两个比较棘手的点一是快速滚动时会看到空白闪烁解决办法是在可视区域上下各加一个buffer区多渲染一部分数据来覆盖滚动间隙二是动态高度的item处理难度很大如果每条数据的高度不固定需要在内容渲染后测量实际高度并维护一个位置缓存测量本身又可能引发二次渲染所以初期我们直接统一了封面图的尺寸规避了动态高度问题。面试官追问“如果产品要求动态高度你会怎么设计”我回答可以维护一个高度缓存池配合ResizeObserver监听元素尺寸变化滚动时用二分查找快速定位当前的起始位置。这个环节给我最大的感受是面试官不会只问你做了什么东西他更关心你踩过什么坑、怎么解决的、如果换一种情况你怎么应对。能体现思考深度的回答才是加分项。3. 前端基础与原理考察八股文面试的进阶版3.1 浏览器渲染原理从输入URL到页面展示项目深挖完之后面试官话锋一转问了一道看起来非常基础但实际考察深度的问题“从输入URL到页面渲染完成这个过程中浏览器做了哪些事情”我把完整流程过了一遍DNS解析域名拿到IP建立TCP连接如果协议是HTTPS还需要TLS握手发送HTTP请求服务端返回HTMLHTML解析构建DOM树同时CSS解析构建CSSOM树两者合并生成渲染树Render Tree然后进入布局Layout阶段计算每个节点的几何位置最后进入绘制Paint阶段再通过合成Composite把图层输出到屏幕。面试官没让我背完就直接打断问了一个细节“CSSOM构建过程中如果遇到CSS文件是阻塞的吗JS文件的执行阻塞DOM解析吗async和defer的区别是什么”我回答CSS是阻塞渲染的——浏览器要等CSSOM构建完成才会开始渲染页面因为如果没有样式信息渲染出来的页面会闪一下无样式内容FOUCJS默认是阻塞解析的因为JS可能通过document.write修改DOM结构所以浏览器遇到script标签会停下来等脚本下载并执行完再继续解析DOM。async和defer都可以实现异步加载脚本区别在于执行时机defer是在文档解析完成后、DOMContentLoaded之前按顺序执行async是脚本下载完成后立即执行执行顺序不保证。面试官追问了句“有没有什么方式可以突破JS文件的加载阻塞”我给出了几个方向使用script标签的async/defer属性关键脚本内联到HTML中避免额外请求非关键脚本可以放在body末尾或通过动态加载的方式延迟执行。3.2 事件循环与异步编程宏任务和微任务面试官说“来写一段代码告诉我输出顺序”然后在白板上写了这道题console.log(script start) setTimeout(() { console.log(setTimeout 1) }, 0) Promise.resolve() .then(() { console.log(promise 1) }) .then(() { console.log(promise 2) }) queueMicrotask(() { console.log(queueMicrotask) }) console.log(script end)这道题考的是事件循环机制同步任务先执行所以先输出script start和script end然后执行微任务队列Promise和queueMicrotask都会进入微任务队列按注册顺序执行所以依次是promise 1、queueMicrotask、promise 2。注意这里promise 1执行完之后返回一个新Promise这个新Promise的then回调会追加到微任务队列末尾所以在queueMicrotask之后执行。全部微任务清空后再去宏任务队列取setTimeout执行输出setTimeout 1。面试官看我答完又追问了一个变体“如果setTimeout延迟是0是不是会立即执行”我说不会即使延迟为0浏览器也有一个最小延迟时间一般是4ms而且必须等当前任务队列和微任务队列都清空之后才会轮到宏任务执行。这也是为什么setTimeout回调里修改DOM会比Promise的微任务更晚生效。我觉得大厂面试考察事件循环重点不是背结论而是看你能不能讲清楚执行顺序背后的调度规则。每次答这种题在脑海里过一遍“当前调用栈是否为空、微任务队列是否为空”这两个判断条件顺序就不会乱。3.3 作用域与闭包从现象到原理面试官在代码题环节又抛了一道闭包相关的问题for (var i 0; i 5; i) { setTimeout(() { console.log(i) }, 100) }这个输出结果应该是5个5因为var声明的i是函数作用域循环结束后i已经是5五个定时器回调共享同一个i。面试官问怎么改成输出0到4我给出了三种方案把var改成let利用块级作用域每次循环产生新的绑定用IIFE立即执行函数传入当前i的值或者用bind方法绑定参数setTimeout(console.log.bind(null, i), 100)。面试官接着问我“闭包的本质是什么”。我当时的回答是闭包是函数和它声明时所在词法作用域的组合。JavaScript的函数在被定义时会保存一个隐藏属性[[Environment]]指向创建时的外部词法环境。当函数在其他地方被调用时引擎会通过这个属性找回原始作用域链把外部变量保留下来这就是闭包产生的原理。函数能够记住并访问它的词法作用域即使这个函数是在当前作用域之外执行的也是从引擎层面的作用域链实现来讲闭包为什么能访问外部变量。追问来了“闭包会带来内存问题吗怎么排查”我说如果闭包引用了外部大对象而这个闭包本身又被长期持有的引用指向正常GC就无法回收这些外部变量可能造成内存泄漏。排查手段主要是用Chrome DevTools的Memory面板做堆快照对比定位到持有大量不释放内存的对象以及用performance面板录制看内存曲线是否持续上涨。使用上需要注意事件监听器用完要解绑定时器要清掉避免把大对象catch进闭包里不需要的生命周期里。3.4 CSS性能与布局一个被低估的考察点面试官突然问了一个我准备时没有重点考虑的知识点“CSS动画和JavaScript动画相比性能上有什么区别为什么CSS动画在某些情况下更好”这个问题我稍微想了一下才回答。CSS动画和JS动画的核心区别在于CSS动画如果只操作transform和opacity可以绕过布局和绘制阶段直接在合成器compositor线程上执行不占用主线程而JS动画通常要操作DOM的几何属性top、left每次变化都触发主线程的布局计算和重绘。所以CSS动画的关键在于把动画限制在合成器可以处理的属性上transform做位移、旋转、缩放opacity做透明度变化。为了触发GPU加速还可以加上will-change: transform或者translateZ(0)但不要滥用因为每个合成层都会占用GPU内存。面试官接着追问“Chrome渲染一帧的流程是什么什么情况下会丢帧”这里其实是在考渲染流水线和帧预算的概念。我回答浏览器每16.6ms生成一帧帧的生成需要经过JS执行、样式计算、布局、绘制、合成等步骤。如果在主线程上执行的任务超过了16.6ms浏览器就无法按时产生下一帧表现出来就是掉帧卡顿。常见的丢帧原因包括JS长任务阻塞主线程、频繁的布局抖动强制同步布局、绘制面积过大、合成层过多导致内存压力过高。优化的核心思路是减少主线程工作量——长任务拆分成小任务避免强制同步布局先读后写原则把可以放合成器的操作尽量放合成器。4. 工程化与架构设计考察前端广度与体系化思考4.1 Webpack构建优化实战工程化这部分问的也比较深面试官问的是“你们的项目是用Webpack还是Vite如果让你对Webpack做个构建优化你会从哪些维度下手”我说了我们早期项目是Webpack后来新项目切了Vite所以两个都要会讲。Webpack构建优化的核心是压缩构建时间维度时间和产物体积维度体积。时间优化方面用thread-loader开启多进程Loader解析用cache-loader或者Webpack5内置的filesystem cache缓存模块编译结果用DLL或hard-source-webpack-plugin做更细粒度的缓存配置resolve.alias减少模块查找范围resolve.extensions减少无谓的文件探测。体积优化方面代码压缩用terser-webpack-pluginJS和css-minimizer-webpack-pluginCSS开启gzip或brotli压缩用splitChunks把公共依赖抽出成单独chunk避免重复打包动态import做路由级代码分割配合preload/prefetch做预加载用webpack-bundle-analyzer分析产物体积。面试官进一步问道“你们是怎么做路由级代码分割的”我说通常是webpack的魔法注释结合动态importconst Home () import(/* webpackChunkName: home */ views/Home.vue)这样每个路由页面会成为独立的chunk只有访问该路由时才会加载对应JS。面试官追问首屏会有什么影响我答首屏需要的JS更少解析执行时间更短启动更快但代价是切换路由时多了一个网络请求的延迟所以需要配合prefetch预加载策略让浏览器在空闲时间段把其他路由的chunk提前下载下来。还有一种是preload策略只针对首屏接下来一定会用到的资源来加载优先级更高。4.2 微前端架构为什么要拆怎么拆聊着聊着面试官突然问了一句“你们有了解过微前端吗如果你们团队要把多个独立系统整合到一个平台上你会怎么设计”这个题问得比较宽我理解他想考的是系统设计能力和对微前端本质的理解。我回答了几层微前端解决了多个团队、多套技术栈、独立部署的子系统需要整合到一个主应用中的问题。它本质上是一种比组件复用更粗粒度的应用拆分与组合机制。常见的实现方案有qiankun基于single-spa的封装支持JS沙箱和样式隔离、无界WebComponent iframe方案、Module FederationWebpack5提供的能力实现运行时共享依赖和代码。面试官追问“你刚才提到JS沙箱它的原理是什么”我说JS沙箱的核心目标是隔离子应用的全局作用域避免子应用之间、子应用与主应用之间的全局变量互相污染。qiankun的实现思路是在激活子应用时对window上新增的属性做快照记录子应用卸载时恢复这些快照还有一种基于Proxy的方案就不用遍历快照而是创建一个代理的window对象每个子应用操作window属性时实际读写的是自己的一份独立代理对象。样式隔离是靠严格约定 CSS前缀或者给子应用容器的选择器加上前缀使样式只对子应用内部生效以及shadow DOM方案。4.3 Node层与全栈能力中间层能解决什么问题面试官问“前端有没有可能涉及Node层你是怎么理解BFFBackend For Frontend的”这题我觉得他是想考察你对前后端协作模式的理解而不单纯是问你会不会写Node。我觉得我在团队里的项目就实践过BFF我们有一个视频推荐页需要同时聚合用户信息接口、视频元数据接口、推荐算法接口三个后端服务的数据。如果让浏览器直接调这三个接口一是请求数太多二是每个接口返回的数据结构和页面需要的结构差异很大前端要做大量适配三是有些接口只给部分用户开放浏览器直连可能会暴露不必要的后端逻辑。所以我们在Node层加了一个聚合网关浏览器只发一次请求Node层并发去调三个后端接口把数据组装成前端需要的结构一次返回。Node层的价值可以概括为聚合请求减少网络往返、数据格式转换适配前端、隐藏后端敏感信息、可以做服务端渲染和模板注入。面试官点了点头又问“你在Node层遇到性能瓶颈怎么办”我说Node是单线程事件循环模型CPU密集型任务会阻塞事件循环。处理思路有把需要大量计算的逻辑拆分出去用worker_threads子线程执行或者把计算任务下沉到独立的服务避免影响I/O型的接口响应。做服务端渲染时尤其要注意复杂度平衡不要为了首屏快而给服务器增加过大的渲染压力必要的时候可以加缓存或者做流式渲染。5. 代码题与场景题实战手写实现考察代码能力5.1 手写实现一个深拷贝函数面试官直接说“写一个深拷贝函数要求支持基本类型、数组、普通对象、函数、Date、RegExp同时要考虑循环引用。”这道题我比较熟核心思路是递归 WeakMap保存引用关系遇到循环引用时直接返回已经创建的对象。我当时的现场实现大致是function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) { return target } if (map.has(target)) { return map.get(target) } if (target instanceof Date) { return new Date(target.getTime()) } if (target instanceof RegExp) { return new RegExp(target.source, target.flags) } if (target instanceof Map) { const cloneMap new Map() map.set(target, cloneMap) for (const [key, value] of target) { cloneMap.set(deepClone(key, map), deepClone(value, map)) } return cloneMap } if (target instanceof Set) { const cloneSet new Set() map.set(target, cloneSet) for (const value of target) { cloneSet.add(deepClone(value, map)) } return cloneSet } const cloneTarget Array.isArray(target) ? [] : {} map.set(target, cloneTarget) for (const key of Reflect.ownKeys(target)) { const desc Object.getOwnPropertyDescriptor(target, key) if (desc value in desc) { cloneTarget[key] deepClone(target[key], map) } } return cloneTarget }面试官看完代码追问了两个细节一个是“为什么要用WeakMap而不是普通Map”我说WeakMap的key是弱引用不阻止垃圾回收。当原始对象不再被引用时映射表中的记录可以被GC回收掉不会造成内存泄漏深拷贝创建的对象和原始对象生命周期一致所以用WeakMap更合适。一个是“Reflect.ownKeys和Object.keys的区别在哪”我说Object.keys只返回可枚举的自有字符串属性Reflect.ownKeys返回所有自有属性键包括Symbol和不可枚举的属性所以在拷贝时能把这些特殊属性的情况也覆盖到不过实际用的时候也要考虑是否需要拷贝不可枚举属性。5.2 手写函数防抖和节流“实现一个防抖函数和一个节流函数并说明它们各自的使用场景。”这题算是前端面试高频中的高频了。我的实现是function debounce(func, delay 300) { let timer null return function (...args) { clearTimeout(timer) timer setTimeout(() { func.apply(this, args) }, delay) } } function throttle(func, interval 300) { let lastTime 0 return function (...args) { const now Date.now() if (now - lastTime interval) { lastTime now func.apply(this, args) } } }面试官问“如果防抖函数的调用非常频繁delay时间内一直有事件触发回调是不是一直不会执行有没有办法让它在等待过程中也执行一次”我回答可以用“立即执行版本”防抖第一次触发立即执行func后续在delay时间内触发都取消等延迟结束之后再触发才会重新立即执行。实现上是在防抖函数里维护一个immediate标志变量。5.3 场景题大列表渲染方案设计面试官出一个综合性场景题“假设页面上有一个非常大的列表可能好几万条数据每条数据渲染耗时较高。请你设计一个方案让用户在滚动时保持流畅。”这个问题他其实想看我综合运用虚拟列表、时间分片、requestIdleCallback这些方案的能力。回答思路分了三个层面数据层面如果数据不需要全部展示只保留当前可视区域和缓冲区的数据其他的都截断丢弃渲染层面用虚拟列表只渲染可视DOM滚动时更新计算起始结束索引并建议在列表项上做稳定key和样式复用避免频繁创建销毁计算层面如果每一条数据的渲染本身很重比如需要做复杂计算可以借助requestIdleCallback把非紧急的计算任务拆分成时间片处理确保每帧都有空余时间再执行计算任务避免阻塞主线程。面试官又问“如果列表项内部还有图片且图片是懒加载的你怎么做”我说图片懒加载用IntersectionObserver监听图片进入视口时再设置src加载同时给外层容器指定占位尺寸避免列表滚动时布局抖动。需要注意虚拟列表滚动过程中不断创建弹出新DOM节点图片懒加载的触发时机要卡在缓冲区内就提前触发否则用户看到图片区域会有明显的白屏等待。这一轮回答完我感觉面试官比较满意因为他开始把问题重心转向了下一方向“你既然提到了性能优化那爱奇艺这种视频网站你觉得首屏优化怎么做更有效”6. 视频场景下的前端性能优化专项6.1 视频网站首屏加载优化这个问题我其实准备了很多毕竟面试的是爱奇艺视频场景肯定绕不开。我从资源加载、渲染、交互三个维度展开说资源加载方面首屏所需的JS按路由拆包尽量控制初始包体用preload提前加载首屏模块依赖用prefetch预加载其他页面路由静态资源上CDN gzip/brotli图片和视频封面用WebP/AVIF格式超过一定尺寸做压缩和裁切。渲染方面骨架屏先用静态HTML或CSS模拟页面结构让用户感觉页面加载很快真实数据到了再替换用服务端渲染或者静态生成减少白屏时间如果没条件上SSR至少保证首屏用的数据在HTML中直接内置首屏直出避免先请求JS再请求数据的串行等待。交互方面关键操作要提前绑定事件首屏大图用loadinglazy延迟非首屏图片上拉加载更多用IntersectionObserver而不是在scroll事件里做高度计算。面试官追问了一个特别细的问题“视频首屏封面图和标题是后端直接下发还是前端获取的”我意识到他想考察的是数据流设计就回答理论上应该由后端直接下发首屏渲染需要的初始化数据也就是第一次HTML请求时把这些数据内联到页面前端不需要二次请求能省一次网络往返。如果能拿到包含封面图地址和标题的基础数据就能快速铺满首屏。6.2 Web Worker在前端的应用场景面试官问“如果页面里有一段很耗时的数据处理逻辑比如对一个大数组做排序或加密直接执行会导致页面卡顿。你有哪些解决方案”我提到了Web Worker方案把耗时任务放到独立的Worker线程里运行主线程只负责接收结果和更新UI。在视频场景下可以把视频数据的分片Hash计算、加解密、大数据量的格式处理等放到Worker里。我还提到最近有一个新趋势是OffscreenCanvas可以把Canvas的绘制操作也放到Worker线程执行主线程只保留最终显示用的画布合成这对复杂视觉效果的渲染优化很有帮助。之前我在项目里用Worker上传大文件的思路是把文件分片后在Worker里计算每个分片的MD5避免阻塞主线程去做哈希计算计算完成后返回给主线程再逐个上传。后来看热词里也包括“前端使用worker上传大文件”说明这确实是热门且被很多团队验证过的方案。如果需要降低计算成本可以考虑用web worker中直接跑hash.js或SparkMD5这类库注意控制每个分片的大小和并发策略避免把Worker线程也压满。面试官还问了一个很实际的问题“Worker之间通信的开销会不会反而成为性能瓶颈”我回答PostMessage的类型是结构化克隆它会把数据复制一份传输大数据时复制成本不可忽略。所以不要把大块数据反复通过postMessage发送最好是只传计算参数和最终结果。如果一定要共享大量数据可以考虑使用SharedArrayBuffer但要注意跨线程竞争的同步问题这个方案浏览器支持情况和潜在的安全限制需要慎重评估。6.3 播放器相关H264解码与视频播放渲染面试官问了一个偏场景的问题“做视频播放器时前端解码H264视频流并在Canvas上播放你会怎么做会遇到哪些问题”这个问题说实话我不算最有把握因为我不是专门的播放器开发但我尽量分析了技术方案。前端解码H264可以用WebAssembly方案用ffmpeg编译成wasm在浏览器里实现软解。如果追求性能可以走WebCodecs API浏览器原生提供视频编码解码能力通过VideoDecoder接口解码H264帧然后把解码后的VideoFrame绘制到Canvas上或者直接交给Video元素渲染。WebCodecs的方案性能好很多因为底层走的是硬件解码通道。潜在的问题包括浏览器兼容性差异、SEI信息处理用于音视频同步、关键帧缺失时首帧解码时间长、内存占用控制解码后的原始帧数据量很大需要及时释放资源。面试官听我说到内存占用追了一句“Canvas上播放视频会一直累积内存吗”我回答如果不显式关闭已解码的VideoFrame或释放对应的Canvas缓冲区确实可能会造成内存持续增长。正确做法是每次绘制完成之后调用frame.close()释放资源。控制解码队列长度不要让解码器无限压入帧数据用背压机制等待渲染完成再解码下一帧。这轮视频专项我觉得面试官应该是有业务背景的问的问题都特别贴近实际业务场景。我也如实说了自己不是播放器方向的专业开发面试官表示理解然后顺势切到了最后一个反问环节。7. 反问环节向面试官提问的正确姿势二面最后面试官问“你有什么想问我的吗”这个环节很多人不重视但我觉得面试官其实在乎的是你有没有真正思考过这个团队和业务方向。我问了三个问题第一个是“爱奇艺前端团队目前的技术栈是什么有没有在推Vue3/React新版本或者新构建工具”他说主站偏Vue技术栈但团队也在尝试新的方向。第二个是“视频业务的前端性能优化你们团队内部有没有一套成体系的监控指标和预算机制新人对这套体系的理解是否有机会深入”这个问题的潜台词是我希望加入的团队是真正把性能当工程来做的而不是只在出了问题才排查。第三个问题是“如果我能通过面试团队当前最大的技术挑战是什么”这个问题能让面试官聊他关心的事拉近距离。可能也是因为反问环节我比较认真面试官最后说“今天聊得挺充分后面流程会有hr跟进”我当时就感觉聊得还不错。面完之后再回头看反问环节的问题本身比答案更重要好的提问能展示你的思考深度和职业成熟度。8. 复盘与总结爱奇艺前端二面的几个核心经验8.1 从这次面试看大厂前端的考察重点从爱奇艺二面的整体节奏来看我觉得大厂前端面试已经不太满足于背八股文了。面试官更像是在做一个“能力画像”的绘画先通过项目深挖了解你实际做过什么、踩过什么坑、有没有思考沉淀然后通过基础原理题检验你的知识是不是成体系能不能层层深入再通过场景设计和代码题考察你把知识落到实际业务的能力。面试过程中我最明显的感受是面试官会把每个回答当成对话的起点而不是终点。你说到一个技术点他会立刻追问下一个层级看你有没有想过更深层的边界和取舍。比如虚拟列表的buffer区、Worker通信开销、深拷贝的WeakMap选择这些问题不会在常规八股文里出现但他们考察的都是你“有没有真正写代码思考过”。8.2 我踩过的几个坑希望你能避开第一个坑项目介绍太空泛。这次面试我一开始介绍项目时讲了很多“我们用了什么技术栈”这类信息面试官没怎么追但后续问题一深入就暴露了一些细节不够扎实。正确做法是介绍项目时直接说“我在这个项目里承担什么角色、解决了什么核心问题、取得的量化的结果是什么”把技术选型的过程放到后续的回答里穿插。第二个坑原理类问题准备不足。比如Pinia响应式原理、微前端沙箱原理这种问题只看过文档没看源码的话很容易车轱辘话来回说。如果你的简历上写了“熟悉xx框架原理”就一定要去源码层面把核心机制搞明白否则面试官一追问就会露怯。第三个坑场景题回答太单一。面试官问大列表优化如果你只说“用虚拟列表”就结束了基本等于放弃了这个题。更好的方式是从多个维度展开数据层怎么处理、渲染层怎么处理、计算层怎么处理、交互层怎么处理分析每个方案的取舍和适用场景。8.3 针对后续面试的复习建议我在准备下一轮面试时给自己列了一个更具体的复习清单这次也分享出来性能优化不能只背纯概念要落到关键指标FCP、LCP、CLS、INP上理解它们各自的测量原理和影响因子知道优化手段对应的指标提升关系。框架源码阅读以“核心响应式原理”和“渲染更新流程”为突破口Vue3重点读effect、reactive、ref、renderer这部分React重点看fiber调度和hook的实现机制。手写题不要只记实现要把设计思考和边界条件也讲清楚比如深拷贝怎么处理循环引用、防抖的立即执行版本、Promise.allSettled等。多给自己出开放场景题比如“实时协作编辑器”“大文件上传”“直播弹幕系统”这类典型高复杂度场景练习多角度分析问题的能力。对视频领域特有的问题要有所准备视频切片策略、首帧优化、解码渲染方案、直播延迟优化等面试视频业务团队这些都是高频方向。这次爱奇艺二面给我的整体感觉是考察很立体、问得很细面试官经验丰富对前端技术有很深的理解和热情。虽然中间有几个瞬间我回答得不够自信但整体来看能用经验加临场推理撑住大部分问题。面完当天晚上我自己把面试过程中所有没答好的点重新整理了一遍后面再遇到类似的问题就不会慌了。最后再分享一个很有用的备战技巧面试前把自己的项目经历和核心技术点全部写成一条一条的“面试官可能的追问树”每个主知识点向下展开至少三层追问然后逐个写清楚答案。提前做这个训练面试时即使遇到没准备过的角度也能快速组织逻辑而不是头脑空白。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
