1. 背景先交代2023年这套面经是怎么攒出来的2023年年初我还在上一家公司做偏业务的前端技术栈以 React 为主Vue 也会一些但谈不上精通。当时动了跳槽的心思主要不是薪资问题而是业务进入瓶颈期重复性的表单和后台页面越写越多技术成长基本靠自学。我给自己定了一个目标上半年集中准备面几家觉得自己够得着的公司阿里云是其中一家。这里先解释一下为什么选阿里云。我身边有不少朋友在云相关团队做前端他们的日常工作除了管理后台还会涉及控制台类产品、数据可视化、甚至一些面向开发者的工具型前端这类业务对工程化、稳定性、性能的要求比普通业务线高很多。我想去一个能逼自己往前走的团队阿里云的前端技术氛围和内部基建在行业内都比较成熟这是我对它的第一判断。投递方式上我优先选择了内推。当时我通过一个前同事联系到阿里云某团队的同学把简历发过去之后对方帮我走了内推流程。从提交简历到接到第一轮面试约面大概隔了四天。整体时间线我整理成了下面这张表方便大家感受节奏节点时间说明内推投递3月上旬简历直接进系统一面投递后第5天约45分钟主要是基础与项目二面一面后第6天约60分钟工程化与场景题三面二面后第5天约40分钟主管面HR面三面后第3天约30分钟聊薪资与入职意向拿到offerHR面后4天定级与薪资确认面试前的一周我做了一套准备动作把简历上每一个项目都重新过了一遍给自己列了十几个可能被追问的问题然后逐个写下口述版本算法和手写题每天刷几道重点不是难题而是 Promise、防抖节流、深拷贝这类高频题React 源码相关的内容挑了几个关键机制比如 fiber 架构的渲染流程和 useEffect 的依赖收集逻辑。准备到后面我发现一个规律面试官的问法千变万化但底层问题就那几类后面我会详细拆。2. 一面基础知识问得细但反而给了你展示的机会2.1 自我介绍怎么讲才能不拖后腿一面开场面试官先让我自我介绍。这里有个很多人容易忽略的点自我介绍不是让你复述简历而是给你一个划定范围的主动权。我当时的自我介绍大概两分钟重点讲了三段经历一是我在上一家公司独立负责过的某个核心模块——一个可视化配置平台从前端架构到业务交付都是我自己推的二是我做的性能优化专项把首屏加载时间从 4 秒压到 1.5 秒三是我业余维护的一个开源组件库虽然 star 不多但能体现自主学习的意愿。讲完这些面试官自然会把后续提问聚焦到我提到的项目上。也就是说自我介绍里提到的每一句话你都提前准备好被深挖的答案。我不建议在自我介绍里堆砌技术名词如果你说“精通 webpack”后面被问到“webpack 的优化链路和持久化缓存细节”而答不上来反而扣分。2.2 事件循环和浏览器渲染别只会背结论自我介绍之后面试官问了第一个正题从输入一个 URL 到页面渲染完成浏览器发生了什么。这道题看似基础但面试官在这个基础上不断加码最后基本变成了事件循环和渲染机制的深挖。他追问了几个细节宏任务和微任务的执行顺序在不同浏览器里是否一致requestAnimationFrame 和 requestIdleCallback 的执行时机有什么区别async/await 在事件循环里是怎么排队的还有渲染帧和微任务之间的先后关系。我如实说了一些结论比如微任务会在每个宏任务之后执行但如果一个微任务又产生了新的微任务会继续清空微任务队列不会把控制权交还给渲染线程。关于 requestAnimationFrame我在项目里用过它做动画帧率控制和批量 DOM 更新所以能多说一些实际的场景。面试官对这个回答比较满意还追问了“如果要在浏览器里做大数据量的列表渲染你会怎么处理”。这里我提到了虚拟列表、切片渲染以及配合 requestIdleCallback 做空闲时间任务调度的思路。整体来说一面考的其实是细节不是表面概念。2.3 React 和 Vue3 的对比考察的是你的选型判断力接下来问到了框架你项目里常用 React那你能说说 Vue3 和 React 的主要区别吗什么时候你会选择 Vue3这个问题我准备过但我知道不能只背两者的 diff 机制差异。我的回答分了三层第一层是编程模型React 的“一切皆 JSX”让组件的表达更自由但也更依赖开发者自身的代码组织能力Vue3 的模板语法加上 setup 组合式 API在状态管理和响应式数据上更直观上手门槛低。第二层是响应式原理Vue3 用 Proxy 做响应式代理可以在运行时精确追踪依赖React 更依赖不可变数据配合 diff 算法没有真正意义上的“响应式”。第三层是适用场景如果是快速迭代的中后台项目团队里有较多偏模板化开发习惯的成员Vue3 会更稳如果项目里有很多复杂交互和自定义渲染逻辑React 的生态和灵活性能撑得住更大规模。最后我还补了一句对我来说技术选型优先考虑团队熟悉度和项目复杂度框架本身不是决定成败的因素配套的工程化体系才是。面试官点头表示认可然后问了一句“你了解 React 18 的并发渲染吗”这是在测你对新特性的关注度。我结合 useTransition 的用法讲了一下并发模式解决的问题也就是大更新不阻塞输入响应这部分因为前段时间刚研究过所以答得比较顺。2.4 手写题题目不深但要注意细节和边界一面有一道手写题实现函数的防抖和节流并且要求说出两者适合的使用场景。这道题很基础但能拉开差距的是细节——你是不是能正确处理 this 指向、参数传递、立即执行选项和取消防抖。我给出的防抖版本是支持 immediate 参数的function debounce(fn, wait, immediate false) { let timer null; let result; return function(...args) { const context this; if (timer) clearTimeout(timer); if (immediate !timer) { result fn.apply(context, args); } else { timer setTimeout(() { result fn.apply(context, args); timer null; }, wait); } return result; }; }节流的写法我用了时间戳和定时器结合的版本保证第一次触发会执行最后一次触发也能补一次执行。写完代码之后面试官问了一个拓展题如果防抖的 wait 设为 0还会有防抖效果吗这里其实是考察 setTimeout 的最小延迟和宏任务排队机制。我说 wait 为 0 时回调会进入宏任务队列在连续触发的情况下回调依然会被合并因为每个回调都会先清除上一个 timer所以防抖仍然有效。这个细节算是加分项。后面还问了一道“实现一个简单的 Promise.all”我用了 Promise 单例和计数器来判断所有任务是否完成并且处理了空数组的情况。一面结束时我对自己的表现打 7 分有把握但也有点紧张。3. 二面工程化和场景题拼的是你真实踩坑的深度3.1 首屏性能优化从指标到落地的完整链路二面面试官看起来是一位资深前端开场没有寒暄直接抛问题你说你做过性能优化那我们从指标说起你会怎么衡量首屏性能我讲了 LCP 和 FCP 这两个核心指标提到用 PerformanceObserver 在业务代码里采集数据上报到监控平台。然后面试官追问如果首屏 LCP 不稳定你在项目里会怎么排查我按之前的实操经验回答先看资源加载的水瀑布图确认是资源问题还是渲染问题再检查图片是否使用了合适的大小和格式有没有开启懒加载然后看 JavaScript 的解析和执行时间如果某个首屏组件依赖的脚本特别大会考虑做代码分割和按需加载最后看服务端返回时间如果 TTFB 耗时高可能还需要后端配合做缓存。面试官问我有没有用 Web Vitals 库我说有但线上一般直接用 PerformanceObserver 封装一层避免引入额外依赖。这里我补了一个自己的经验LCP 指标有时候会被“伪装”得很好比如页面首屏是空白但背景图加载完成LCP 元素是一个不可见的图片这时候要做元素可见性判断不能只看 LCP 数值。面试官明显有共鸣说明这道题答到了点子上。3.2 微前端方案选型什么情况下我会用 qiankun聊到微前端是因为我简历里写了一个多团队协作的项目。面试官问你们的项目为什么会考虑微前端如果让你重新做一次还会选这个方案吗我如实说当时因为多个团队要并行开发同一个系统每个团队的技术栈不完全一致用微前端可以把不同子应用隔离起来团队间互不阻塞。我在方案选型时对比了 qiankun 和 iframe 方案最终选了 qiankun。面试官很犀利马上追问如果业务复杂度不高你还会选微前端吗我说如果团队就一个业务体量也不大微前端只是增加复杂度不建议用。微前端带来的子应用加载、通信、样式隔离和状态同步每一项都要有配套方案不是简单地引入一个框架就能解决的。他继续问 qiankun 的原理子应用是怎么挂载的、JS 沙箱怎么做样式隔离。我讲了 HTML Entry 的加载方式子应用会在容器里执行通过 proxy 沙箱隔离全局变量样式隔离则处理不好会有坑比如子应用的全局样式互相覆盖需要约定命名空间或者在构建阶段给样式加前缀。这段交流比较深入面试官最后说了一句“你把这些坑讲得像自己踩过”说实话确实是我当时连续加班排查环境问题换来的一点不虚。3.3 大文件上传Worker 在这里不是噱头二面最后一道场景题是如果让你做一个上传组件支持上传几个 GB 的大文件你会怎么设计我先讲了整体方案文件分片每个分片独立上传后端按顺序重组前端做并发控制避免一下子发出几百个请求把浏览器打崩同时做断点续传每次上传前先向后端查一下哪些分片已经上传过只传缺失的。面试官追问你知道如何使用 Web Worker 做上传吗为什么需要 Worker这个问题其实有实际价值。大文件上传时如果要在主线程里做分片、读取文件、计算哈希比如用 spark-md5 计算文件指纹这些操作会阻塞 UI 线程用户点击页面会卡顿。把文件读取和哈希计算放到 Worker 线程里主线程只负责发起网络请求和更新进度条体验会好很多。我给的方案是先在 Worker 里完成分片和哈希计算然后把分片数据通过 Transferable Object 传回主线程这里用到了 transfer 参数避免结构化克隆的额外内存拷贝。我还补充了并发控制的实现思路遍历分片用一个计数器维护当前并发数超过上限就等待每个分片失败做三次重试重试仍失败就标记为失败保留断点信息允许用户下次继续。面试官听完说“这个方案可以直接落地”这句话算是对整个回答的肯定。3.4 监控系统的设计思路报错链路和资源加载二面快结束时面试官问了一个开放题如果让你给公司搭一套前端监控系统你会怎么做我按三个维度回答错误监控、性能监控、行为埋点。错误监控上用 window.onerror 和 unhandledrejection 捕获全局错误配合 React 的错误边界捕获组件级渲染错误性能监控用 PerformanceObserver 采集 FP、FCP、LCP、INP 等指标行为埋点则根据业务需要自定义上报。面试官追问上报数据的格式怎么设计怎么保证大流量下监控系统不拖垮业务我说上报要合并比如把十秒内的错误日志打包成一条请求发送批量上报上报接口要独立部署并且开启跨域即使业务系统挂了上报不能阻塞上报请求用 navigator.sendBeacon 在页面卸载时保证数据能发出去。面试官对这个方案没有继续深挖但我能感觉到他考察的不只是一两个知识点而是你有没有真正把系统级的东西想通过。4. 三面主管面更看重业务视野和技术判断4.1 你怎么理解“稳定性高于一切”三面是团队主管开场就抛出一个偏理念的问题你做前端也几年了你觉得阿里云这类云产品前端和普通互联网业务前端最大的区别是什么我结合自己的理解回答普通业务前端追求的是迭代速度和转化率而云产品前端面对的往往是开发者用户他们对控制台的稳定性和响应速度更敏感一个按钮误触可能导致用户配置的失效这种场景下稳定性优先级最高。所以前端不能只考虑功能实现还要考虑操作确认、撤销恢复、异常降级、错误提示这些细节。主管追问如果要给控制台某个页面做增强把原来需要后端计算的指标搬到前端算你会怎么判断能不能做我回答的思路是先评估计算量如果数据量在几 MB 以内前端可以承担如果数据量到几十 MB就要权衡用户设备的性能还要考虑数据安全有些数据不应该下发到浏览器端后端计算更合适。这个“权衡”的过程主管比较认可他说前端到了这个阶段不只是写页面而是在做技术决策。4.2 问你职业规划真实比漂亮更重要主管面必然会问职业规划。我提前想好了自己的答案两三年内希望能在一个技术密度高的团队里把前端工程化和性能优化做到更深的程度能独立负责一个复杂系统的前端架构再往后希望能带小团队但前提是自己技术上站得住脚。这里我的经验是职业规划最好的回答方式是“我对本专业有持续的热情而且有清晰的方向”不要太虚。主管问我“你有没有考虑过转后端”我明确说没有因为我觉得前端领域还有很多值得钻研的东西比如渲染性能、可视化、跨端方案等等。这个回答不能显得猴急也不能显得没有野心。我给出了一个具体的自我评估目前在前端工程化方向有一些积累但在 Node.js 服务端和云原生领域还欠缺经验未来会补充这些短板。4.3 向面试官提问的环节怎么问才有信息量主管面最后留了十分钟让我提问我问了三个问题一是团队当前前端的主攻方向是什么是控制台体验还是开发者工具二是团队内部对工程化建设重视程度如何有没有专门的基建小组三是这个岗位未来的成长空间大概是什么方向。这三个问题既表达了我对团队的认可也帮助我判断这个岗位是否真的适合自己。有一个细节想提醒大家提问环节非常关键但很多人只会问“加班多吗”“薪资多少”。这些可以问但最好不要在这轮问应该在 HR 面或拿到口头 offer 后再确认。技术面提问环节问业务、问技术、问团队建设会显得你更像一个候选人而不是一个求职者。5. HR面与整体流程里的实操细节5.1 HR面聊了哪些问题HR面比我预期的要快。问题主要围绕三块离职动机、期望薪资、入职时间。离职动机我如实说上一家业务进入成熟期技术挑战变少我更希望接触复杂度更高的场景。这个理由既不会诋毁前公司也表达了自己积极的一面。期望薪资我提前做了功课结合市场行情和阿里云的定级范围给出了一个区间而不是一个具体数字。HR追问为什么是这个区间我说基于自己目前薪资水平和市场对标。在 HR 面里“合理的薪资区间 一定的弹性”是比较稳妥的策略报得太高容易失去机会报得太低后期会后悔。建议大家在面之前多看看招聘平台和脉脉上的讨论大致了解目标团队的职级和薪资区间。5.2 远程面试的三个坑环境、白板和回放2023年的面试基本都是远程这里有几个实操细节特别想提醒大家第一提前把视频会议软件装好测试摄像头、麦克风、共享屏幕的权限。面试当天提前十分钟进会议不要等面试官上线你还在调试设备。第二手写题环节一般会开在线编辑器如果你平时用惯了 IDE建议提前适应一下网页编辑器的代码提示和快捷键否则写着特别别扭。我当时因为不熟悉在线编辑器的自动缩进写代码节奏被带乱了一小会儿。第三建议把自己面试时的屏幕录下来后面回放复盘。很多细节只有回看时才会发现比如某道题你明明想到了关键点但没说出口或者某个术语的发音不对这些问题在当场很难察觉。5.3 定级与 offer 的几点观察从整体流程来看定级主要由面试过程中的综合表现决定一面二面考察技术深度和项目能力三面主管面考察业务视野和软素质。同样一个岗位不同候选人的定级会有差异。我不能也不应该给出具体的职级判断标准但可以分享一个规律面试中能主动把技术方案讲成长链路从问题分析到方案选型再到落地效果的候选人往往比单纯答对题目的候选人拿到更高级别的机会更大。最终我拿到的 offer 是一个资深前端开发的定位薪资涨幅在我预期范围内。但说实话经过这几轮面试对我帮助最大的不是薪资数字而是从面试官那里吸收到的思考方式尤其是“不要只给结论要给出结论背后的链路”这个原则在后来的工作中一直影响着我。6. 复盘真正对我有帮助的几件小事6.1 建立错题本把“不会的题”变成“会的题”面试结束后我把自己能记住的所有问题都录入了一个文档按“基础/框架/工程化/性能/场景题”分类。对每一道答得不够好的题我都用“正确答案 我的原错误答案 两者的差距”三段式重新记录一遍。这样做的好处是几个星期后如果再遇到类似的题我不会只在“我好像见过”这个层面而是能完整地说出思路。错题本里不只有知识题还有场景题。举个例子二面问的大文件上传我当时讲到了 Worker 和分片但没有把“为什么把哈希计算放到 Worker 而不是主线程”这个原因解释清楚面试官追问后我才补上。我复盘时把这个问题单独记了一条后来真的在朋友公司的面试中遇到了完全一样的题两次表现完全不同。6.2 模拟面试的价值练“说”和练“听”同样重要我准备了半个月之后找了一位也在准备跳槽的前同事互相模拟面试。我们约定每个人当面试官轮流提问每次 40 分钟面试后互相点评。这个方式非常有效因为很多知识点你觉得自己懂了但要用口头方式讲清楚尤其是让没有你上下文的人听懂完全是另一种能力。模拟面试帮我暴露了两个问题一是回答问题时容易一开始就把细节全讲完没有先给框架导致面试官很难抓住重点二是在面对不会的题时我习惯停顿太久而不是用“我理解这个问题的核心是……”的方式先接住问题再思考。后来我在正式面试里刻意调整了这两个习惯反馈明显变好。6.3 心态管理面试不是考试而是一次双选最后想聊一个比较虚但实际很重要的点心态。2023 年的前端市场整体不算乐观投递简历石沉大海的情况非常正常不要因为一两家的失败就否定自己。我在这轮面试过程中也经历过一面就挂的情况当时确实有点灰心但复盘后发现自己在算法题上准备不足后面集中刷了两周效果立竿见影。面试本质上是一次双选不只是一家公司考核你你也在考核这家公司。如果在面试过程中你发现面试官问的问题机械、死板或者团队的技术栈和业务方向不符合你的预期及时放弃并不是坏事。我在这次求职里就主动终止过一家的流程因为二面面试官全程都在问一些毫无关联的冷门八股回答完之后我判断这个团队的技术追求可能和我们不一样。6.4 一些想留给后来者的建议如果要我用三句话总结这次阿里云面试复盘第一基础一定要牢固但不要只背结论要能把结论推演出来。事件循环、渲染机制、框架原理这类题面试官不会只满足于“是什么”他会继续问“为什么”和“如果反过来会怎样”。第二简历上写的项目每一个都要准备好被深挖到细节。你可以不写很多项目但写上去的必须能讲清楚背景、难点、你的方案、效果量化、复盘反思。第三面试结束后尽量记录下所有能记住的题目和对话这既是错题本也是你下一场面试的最好素材。我当时把这些话记在自己的面试复盘文档开头事后看真正让面试表现提升的不是某一套题库而是不断自我审视和修正的习惯。