这份爱奇艺前端二面面经，我拖了两周才动笔写。不是懒，是有些题当时没答好，回来复盘越想越觉得自己“欠练”，那种被按在地上摩擦的感觉需要缓缓。现在情绪平复了，把整场面试从流程到题目到回答思路，原原本本拆给大家看。如果你正在准备中大厂前端岗，这篇文章能帮你少踩好几个坑。
1. 一面复盘：能走到二面，靠的不只是背八股
1.1 一面到底考察什么
爱奇艺的一面整体节奏偏“稳”，面试官没有上来就甩脑经急转弯，而是先花二十分钟过了一遍简历上的项目。我介绍的是之前做的视频后台管理系统，重点聊了列表页性能优化和权限控制这两块。一面考察的点比较常规：JavaScript基础（原型链、闭包、事件循环）、CSS布局（Flex和Grid对比）、HTTP缓存、Vue响应式原理、还有两三道中等难度的算法题。
一面给我最大的感受是，面试官对“基础是否扎实”的判断不靠背题，而是靠“追问”。比如问到Vue响应式时，他会顺着“数组的元素被修改为什么不能触发更新”这个点一直往下追，直到你说出“需要重写数组方法”或者“Vue3里用Proxy解决了”才肯罢休。这种连环追问的方式，是很多二面的前奏，目的是探测你知识边界在哪里。
1.2 二面跟前一面有什么不一样
如果你以为二面只是“一面太难了加一轮”，那就大错特错了。二面通常由更资深的工程师或者技术Leader来面，考察重心从“你会不会”彻底转向“你为什么会”“你怎么证明你行”。
我这次二面的面试官是负责播放器业务的资深前端，开场就说了这么一句：“我们不背八股，讲你真实做过的项目，讲你怎么思考和取舍的。”这一下就把我的期待值拉高了——后面问的每一道题，几乎都要求“项目经历+技术方案+取舍过程”三位一体地回答。
所以，各位如果准备二面，请务必放弃“背题”的幻想。二面考的是你真正参与过的项目的深度，以及你把技术方案讲清楚的能力。简历上没有做过的事，最好一个字都不要写，因为你根本经不起深挖。
2. 二面整体流程与考察主线
2.1 面试节奏和考察方向
整场面试大约五十分钟，流程大致是：
- 自我介绍（约5分钟）
- 项目深挖：挑一个你认为最有代表性的项目讲（约15分钟）
- 场景设计题：基于爱奇艺业务场景出题（约15分钟）
- 手写代码题（约10分钟）
- 开放式问题和个人提问环节（约5分钟）
从考察方向来看，二面重点集中在这几块：项目复杂度与你在其中的角色、性能优化真实案例、跨端与缓存策略、架构设计能力、代码质量意识。这些方向基本上覆盖了资深前端工程师日常工作的核心。
2.2 爱奇艺业务场景下的前端侧重点
爱奇艺作为视频平台，前端业务有几个显著特点：首屏性能要求极高（用户打开页面就想看到内容）、长列表无处不在（剧集列表、评论列表、推荐流）、视频播放相关技术栈深、大文件上传与断点续传是刚需、多端适配复杂（Web/H5/小程序/客户端WebView）。
面试官出的每一道题，几乎都围绕这些业务特点展开。这也提醒了我一个很重要的点：面一家公司之前，一定要花时间研究它的业务形态和技术栈，针对性地准备。不像一些小公司面试题全是“背诵版八股文”，大厂更在意你的技术方案能不能落地到具体业务场景里。
3. 核心题目逐题复盘：题目与回答思路拆解
3.1 项目深挖环节：一个性能优化案例的完整复盘
面试官让我讲一个最有代表性的项目，我讲的是一个低代码表单搭建平台。这个项目的核心痛点在于：表单配置复杂、渲染性能差、用户拖拽体验卡顿。我提到自己做了组件懒加载、虚拟滚动、渲染函数优化等优化，首屏加载时间从4.5秒降到了1.8秒。
面试官的追问链非常凶悍：
- “1.8秒是怎么测出来的？用的是首屏时间还是FCP还是LCP？”
- “虚拟滚动是只虚拟了可视区吗？缓冲区域你怎么设的？数据量大约多少条才触发？”
- “组件懒加载之后有没有出现白屏闪烁？你是怎么解决的？”
- “你做的这些优化，有没有上线前后的对比数据？”
这里我犯了一个典型的错误：把“听说过的方案”当成“自己做过的事”来讲。虚拟滚动我当时只了解基本原理，并没有真正在项目里自己实现过。结果面试官一问缓冲区和滚动事件频率控制，我的回答开始变得含糊。
后来复盘我意识到，正确做法应该是：选一个自己真正深度参与过的优化，哪怕只是优化了一个列表页，只要把细节讲透——为什么慢、用什么工具定位、做了哪些优化、每一项优化带来了多少收益、数据怎么埋点统计——都比“背一个标准答案”强十倍。
3.2 场景设计题：大文件分片上传与断点续传
这是让我眼前一亮的一道题。面试官问：“假设用户要上传一个2GB的视频文件到爱奇艺后台，浏览器把文件读进内存不现实，网络波动还容易断了重来，你会怎么设计上传方案？”
这是一个非常典型的前端工程化场景题，我建议大家认真对待这类题，因为它考察的是你“能不能把一个复杂问题拆解成可执行的方案”，而不是“会不会背API”。
我当时的回答思路是这样的：
第一，File API是拿文件的入口，但拿到的File对象不能直接塞进请求体发给服务器，2GB的文件一次性上传既不现实也容易超时。所以要分片。
第二，分片的核心是“一片一片地切，一片一片地上传”。用File.prototype.slice方法，把大文件切成固定大小的小块，比如每片5MB，2GB就是400片。每片独立上传，后端的接口设计是接收chunkIndex、chunkTotal、fileHash等参数。前端用Promise.all控制并发数，比如同时上传5片，防止浏览器被并发请求拖垮。
第三，断点续传的关键在于“秒传”和“失败重传”的判断。上传前先向后端发一个查询请求，带上文件的fileHash，后端告诉你哪些分片已经传过了，前端只传缺失的片。fileHash可以在前端用SparkMD5之类的库计算，注意要使用增量计算，不然2GB文件卡死浏览器。
第四，Web Worker在其中的作用。在我的方案里，我用了一个Web Worker来跑两个耗时任务：计算文件Hash、读取文件分片。主线程只负责调度上传任务，这样UI不会卡顿。面试官这里追问了一句：“Worker里能不能直接拿到File对象？分片是在主线程切还是Worker里切？”我答上来File对象可以结构化克隆传入Worker，分片也可以直接在Worker里用slice完成。这块面试官点了点头。
第五，“失败重传”之外还要考虑“上传中的网络波动”。我的方案是每一片都做失败重试，重试次数上限设为3次，失败后标记该片，最后统一汇总未完成的分片重新上传。面试官追问：“如果用户中途退出页面怎么办？”答案是：把上传进度保存在localStorage或者indexedDB里，下次进入时读取进度继续上传。
这道题的踩坑提示：不要一上来就抛FTP、OSS这些后端名词，先把浏览器端能做的事讲清楚，把分片、并发控制、进度存储、失败重试这几个关键点覆盖到位。
3.3 浏览器缓存与服务端缓存的组合拳
爱奇艺前端有一个典型问题：视频封面、剧集海报、用户头像这类静态资源数量巨大，并且几乎每个页面都要加载。如何保证资源加载快、不重复请求、同时还能在资源更新时及时生效？这就是面试官给我出的第三道题：结合爱奇艺的静态资源场景，聊聊浏览器缓存方案。
这道题我答得比较顺，因为之前专门研究过。我的思路分三层：
第一层是强缓存。对于图片、CSS、JS这类带hash指纹的静态资源，使用Cache-Control: max-age=31536000（一年）做强缓存。因为文件名里带了hash，内容变了文件名就会变，浏览器自然请求新文件，不存在过期问题。
第二层是协商缓存。对于不带hash的资源，比如HTML入口文件，使用Cache-Control: no-cache加ETag或者Last-Modified，每次都要向服务器确认资源是否过期，304就走缓存。
第三层是Service Worker。面试官追问了一句：“如果用户离线了，你的页面还能打开吗？”这里就引入Service Worker做离线缓存了。核心思路是：首次访问时把HTML、CSS、JS静态资源放进Cache Storage，用户再次访问时走Service Worker拦截请求，命中缓存就直接返回；网络请求失败时再回退到缓存。这招也叫“离线优先”策略。
这里我额外补充了一点：视频站点通常会给不同清晰度分配不同域名，静态资源也分配给独立的CDN域名，比如i0.hdslb.com这种形式，目的就是减少Cookie传输和突破浏览器同域名并发连接数限制。这些细节说出了“你真的在视频站待过”的信号。
3.4 微前端架构的选型与取舍
因为简历里写了“负责过多个中后台系统的重构”，面试官顺着问了一句：“你接触过微前端吗？如果现在有三个后端系统、三个前端应用，要合并成一个统一的工作台，但各个系统技术栈不一致，有Vue2、有Vue3、还有React，你会怎么设计？”
我先给出了总体思路：用微前端架构，把每个子系统作为独立子应用接入主应用，各子应用保持技术栈隔离，主应用提供统一的导航、鉴权和公共布局。
然后我对比了目前主流的微前端方案：qiankun基于single-spa，做了HTML Entry和JS沙箱，接入成本低，适合大部分中后台场景；wujie是京东开源的无界方案，用Web Component隔离样式和DOM；micro-app类似。我更推荐qiankun，因为它的社区生态最好，踩坑案例最多，遇到问题容易找到答案。
面试官追问了一个关键点：“子应用之间的状态怎么共享？”我当时的回答是：设计上尽量不让子应用之间有强耦合状态，共享的数据通过主应用提供的全局Store或者自定义事件来传递，比如用户登录信息、权限点列表、菜单配置。如果子应用之间需要传业务数据，优先走URL参数或本地存储，而不是window全局变量。
这个回答面试官比较认可，因为我没有把微前端“神话化”，而是强调“能不用就不用，用了就要做好隔离和边界的约定”。
3.5 手写题：一个Promise.all限制并发数
到了手写代码环节，面试官出了一道题：“实现一个函数pLimit，传入并发数limit和一个异步任务数组，要求最多同时执行limit个任务，所有任务执行完毕后返回结果数组，任意一个任务失败就reject。”
这个题在中小公司面试里很常见，但在大厂二面出现，考察点就比较深了：你要理解Promise的调度机制，要会处理并发池的“替补”逻辑，还要写代码时注意边界情况。
我当时的实现思路是：
维护一个正在执行的任务池running，一个待执行的任务队列queue。不断从队列里取出任务放入池中，直到池中任务数达到limit。每个任务无论成功还是失败，都在结束后从池中移除，并从队列再取一个新任务顶上；所有任务结束后统一resolve结果。
下面是我事后整理的标准实现版本：
function pLimit(tasks, limit) { let index = 0; const results = new Array(tasks.length); let completedCount = 0; return new Promise((resolve, reject) => { function worker() { if (index >= tasks.length) return; const currentIndex = index++; const currentTask = tasks[currentIndex]; currentTask() .then((result) => { results[currentIndex] = result; }) .catch((err) => { reject(err); }) .finally(() => { completedCount++; if (completedCount === tasks.length) { resolve(results); return; } if (index < tasks.length) { worker(); } }); } for (let i = 0; i < Math.min(limit, tasks.length); i++) { worker(); } }); }写完代码之后，面试官追问：“这个实现里reject之后还会继续执行任务吗？如果不需要继续执行，怎么处理？”我当时答得不够好，只想到用一个isFailed标志位，在reject后直接返回。
他其实就是想考我“Promise一旦reject，后续还有可能继续启动新任务”这个问题。更严谨的做法是加一个isFinished标志，reject之后不再启动新的worker，同时把剩余的任务“丢弃”。只是我当时写得太急，忽略了这层。
提示：手写题不求“花哨”，但一定要把边界条件和失败处理讲清楚。写出能跑的代码只是及格线，把异常情况考虑周全才是加分项。
4. 开放式问题的回答思路与个人心得
4.1 如何看待前端工程化
这道题出现在二面最后，当时面试官用了非常随意的口气问：“做前端也有几年了，你怎么理解前端工程化？它到底解决什么问题？”
我当时想了想，给出了三层回答：
第一层，工程化解决的是“人”的问题。多人协作时，代码风格统一、目录结构规范、Git提交规范、Code Review流程，这些靠的是工具链来约束，靠人自觉是不现实的。
第二层，工程化解决的是“效率”的问题。开发环境的热更新、构建优化、部署流程自动化、一键回滚，这些能把“从改代码到上线”的时间从小时级压缩到分钟级。
第三层，工程化解决的是“质量”的问题。单元测试、E2E测试、自动化代码扫描、构建产物大小监控、错误上报监控，这些手段能让你在用户反馈之前就发现线上问题。
面试官听我讲完后，追问了一句：“你现在的工作里，有哪些工程化实践是你自己推动落地的？”这里要注意，如果你简历里写了“推动团队工程化建设”，一定要准备好一个具体的例子，比如“统一了项目的代码规范，接入了ESLint和Stylelint，配置了husky钩子，写了一个CLI工具一键生成符合规范的模板”。有实际产出，这类题才能答得让人信服。
4.2 对AI辅助开发的看法
这道题其实在2026年的前端面试里出现频率非常高，很多公司都开始考察候选人对AI编程工具的理解。我当时的回答没有吹得天花乱坠，也没有提任何敏感工具，只是阐述了一个观点：AI能提高写代码的速度，但不能替代程序员做架构决策和业务理解。
我举了一个实际例子：之前做表单平台的时候，我用AI生成过一批重复的表单校验代码，确实节省了不少时间。但遇到复杂的联动校验逻辑，AI生成的代码往往需要大量“调教”，反而比自己手写更费时间。所以我的策略是：AI适合做“重复度高、逻辑简单”的代码生成，业务核心逻辑和数据模型设计一定要自己把控。
这个回答让面试官表情放松了不少。他给我补充了一句：“我们面试不排斥用AI工具，但我们更希望候选人清楚哪些事情必须自己思考。”这句话我记到现在。
4.3 你还有什么想问的
最后一个环节，面试官照例问：“你有什么想问我的？”千万不要说“没有”。这是你反向了解团队、展示自己思考深度的最好机会。
我问了两个问题：
第一，“播放器业务的前端团队，目前在技术选型上有什么方向性的规划吗？比如WebCodecs、WebGPU这些新能力有没有计划尝试？”这个问题展示了我对视频前端技术方向的关注。
第二，“团队对资深前端工程师的期待是什么？如果入职后的前三个月，你认为最重要的事情是什么？”这个问题能帮你判断这个岗位的真实需求和团队文化。
实操心得：别在反问环节问薪资、加班这类问题，容易让面试官觉得你在意的东西和岗位不匹配。问团队技术方向、人才期待、业务规划，是相对稳妥且加分的选择。
5. 复盘总结与避坑建议
5.1 我踩过的三个坑
第一个坑：面试前没有深入研究爱奇艺的业务场景。虽然准备了常规的缓存、性能优化、Vue原理，但对“视频平台前端特有的技术点”准备不足。如果提前研究了视频播放器相关技术、大文件上传场景，答题时会更精准。
第二个坑：简历中写了“虚拟滚动”，但没有做到“真懂”。被面试官追到缓冲区设置、滚动事件防抖策略、测量高度的方式时就露馅了。建议各位在简历上只写自己真正做过、能讲清楚细节的技术点，宁可少写，不要虚写。
第三个坑：手写题没有先和面试官确认边界条件。题目要求“任意一个任务失败就reject”，但我没有考虑“已有任务在跑时失败，后续任务要不要启动”这个问题。写代码前至少花30秒和面试官对一下输入输出和异常场景，比闷头写完再改要高效得多。
5.2 给准备面试的人的建议
如果你想冲刺爱奇艺或同级别的中大厂前端岗，我总结了几条切实可行的准备策略：
第一，把简历里每个项目都拆成“方案+细节+数据”的结构。比如性能优化，不能只说“我用懒加载优化了首屏”，要能说出“首屏从X秒降到Y秒，用的工具是Chrome Performance面板，具体瓶颈是Z，优化手段是懒加载+资源压缩+接口并发请求合并”。真实数据和细节是面试官最看重的。
第二，针对目标公司的业务场景做专项准备。面爱奇艺就多想想视频播放页的体验优化，面电商就多想想大促场景的流量峰值应对，面教育公司就想想音视频互动和实时通信。每家公司业务不同，前端侧重点也完全不同。
第三，手写题提前练熟高频场景。Promise并发限制、防抖节流、深拷贝、图片懒加载、模板字符串解析、虚拟列表基本实现，这些都属于前端面试的高频手写题。建议用“先写实现，再自问自答边界情况”的方式来练。
第四，一定要准备“反问环节”的问题。这不只是礼貌问题，也是你了解团队是否匹配自己的机会。问技术方向、团队规划、岗位期待，都能暴露很多信息。
5.3 这轮面试给我的价值
现在回过头来看这轮二面，我的感觉是：真正的资深前端面试，不考记忆力，考的是你在真实业务里的思考深度和解决问题的方式。
能不能说出虚拟滚动的缓冲区怎么设，代表了你是“用过”还是“研究过”；能不能说清微前端的边界策略和沙箱原理，代表了你是“搭过架子”还是“写过业务”；能不能画出整个大文件上传的架构图，代表了你是“调过接口”还是“设计过系统”。
爱奇艺二面让我最满意的部分，反而是那些我没答好的地方。它们像一面镜子，清清楚楚地照出了我知识体系里模糊的区域。面试结束后，我立刻把虚拟滚动从原理到实现完整读了一遍，自己写了一个支持动态高度的虚拟列表，顺手把Promise并发限制这个实现补上了失败取消的逻辑。失去一次机会不可怕，可怕的是面试都面完了，你还不知道自己哪里不会。
最后分享一个我自己复盘时用的办法：每次面完试，趁记忆新鲜，把面试官问过的每一道题、我的回答、正确的思路整理成一篇文档。文件夹里存这么五六篇面经之后，你会明显感觉到自己的知识盲区越来越少。祝各位都能拿到心仪的offer。
