前端这块的面试最近几年有个特别有意思的现象简历上写着“精通 JavaScript”的人越来越多但真坐到面试桌前能把一道经典题聊透的反而越来越少。很多候选人不是不会而是对常见题的认知停留在“背答案”层面一旦面试官顺着答案往下追问马上就露怯。这篇《前端专业面试真题(1)》不打算做成八股文大全而是换个角度我尽量还原面试现场把题目背后的出题逻辑、追问路径、以及真正能拿高分的回答骨架拆开讲清楚。你把它当成一份“面试官视角的复盘笔记”来读就好。第一期选了 5 道高频且很有区分度的题覆盖了 JavaScript 基础、异步机制、框架原理、浏览器渲染和开放设计题正好对应一场技术面里最常见的几个考察板块。1. 作用域与闭包一道送分题为什么有人能答出三个层次1.1 真题原文与现场实录先看一道非常经典的题目很多面经里都出现过但现场表现差距极大for (var i 0; i 5; i) { setTimeout(function() { console.log(i); }, 100); }请问这段代码输出什么如果想输出 0 到 4怎么改我在面试里几乎每次都会问这道题或者它的变体。它考察的知识点非常集中var的函数作用域、闭包对变量的引用方式、以及宏任务回调的执行时机。但就是这么一道看似“基础中的基础”的题候选人的回答通常能分出三个鲜明的层次。1.2 三个层级的回答拆解第一层候选人直接报答案输出 5 个 5。问他为什么能说出“因为 var 是函数作用域循环结束后 i 已经变成 5setTimeout 里的函数执行时读取的是同一个 i”。到这个程度算合格但也就止步于此。第二层候选人会主动补充修复方案。常见的修复方式是用闭包包一层for (var i 0; i 5; i) { (function(j) { setTimeout(function() { console.log(j); }, 100); })(i); }或者干脆用letfor (let i 0; i 5; i) { setTimeout(function() { console.log(i); }, 100); }能给出这两种方案说明对var和let的区别、IIFE 创建独立作用域这两件事是有认知的。但如果只停留在“能改对”这个层面我觉得还差了最后一步。第三层候选人会把let方案的原理也讲透。let在 for 循环的每次迭代中都会创建一个新的词法环境循环变量i被绑定到了当前迭代的块级作用域上。换句话说每次循环都生成了一个新的绑定闭包引用的是各自迭代的那份绑定而不是共享同一个变量。加上let的暂时性死区特性循环体内在声明之前访问i会直接抛 ReferenceError这跟var的变量提升行为完全不同。1.3 面试官追问链var 换成 let 之后会发生什么这道题的高频追问方向有两个我几乎每次都会挑一个继续往下探。第一个追问是如果我把setTimeout换成Promise.resolve().then()输出顺序会变吗这其实是在把作用域题往事件循环的方向引。Promise回调属于微任务会在当前脚本执行完后立即执行而不是像setTimeout那样等至少 100ms。但for循环本身是同步执行的循环会在第一轮微任务执行之前就完整跑完所以var情况下依然输出 5 个 5。这个追问能筛掉一批“背了答案但没理解执行时机”的候选人。第二个追问更贴近实战如果业务里不得不依赖循环结束后的某个值但又要保留每次循环的中间状态除了闭包和let还有什么办法这时候如果候选人能提到把逻辑抽成函数、用Array.prototype.forEach替代for循环或者用bind传参都是加分项。因为forEach每次迭代都会调用一个函数回调参数本身就是独立传入的。这个方案在实际业务里其实很常用比 IIFE 写法直观多了。1.4 这道题背后真正想考察的能力作为面试官我其实并不指望候选人把这题的每个变体都答得滴水不漏。我更想看的是候选人面对一个“翻车现场”时能不能自然地说出“问题出在变量作用域上”“闭包保存的是引用而不是值”这两句话。能主动说出这两句话的人说明他对 JavaScript 的执行模型是有体感的而不是单纯背过一道题。这道题背后真正的考察点是你能不能在工作中定位到类似 bug当页面里某个定时器回调读到的数据总是不对时你能不能顺着作用域链和闭包引用这两条线去做排查从这个角度说它与其说是一道题不如说是一道“最小化的线上问题排查模拟”。2. 事件循环与 Promise 执行顺序压轴必答题里的三个深水区2.1 一道让不少人翻车的现场输出题第二道题是一道典型的执行顺序题大家应该都见过类似版本async function async1() { console.log(async1 start); await async2(); console.log(async1 end); } async function async2() { console.log(async2); } console.log(script start); setTimeout(function() { console.log(setTimeout); }, 0); async1(); new Promise(function(resolve) { console.log(promise1); resolve(); }).then(function() { console.log(promise2); }); console.log(script end);我一般会给候选人两分钟让他写出完整输出顺序。这道题对熟悉事件循环的人来说并不难但能把顺序完整写对、并且每一步解释清楚的人比例并没有想象中高。正确答案是script start async1 start async2 promise1 script end async1 end promise2 setTimeout2.2 微任务与宏任务的排队规则这道题很容易在async1 end和promise2的顺序上出错。关键点在于await做了什么很多候选人知道await要等右侧的 Promise 完成却不清楚await底层的“语法糖”行为。await会先把右侧表达式执行掉然后暂停当前 async 函数把后续代码包装成一个微任务排队。也就是说console.log(async1 end)并不是在await async2()执行完的瞬间就立刻执行的而是先进入微任务队列。问题来了它是在什么时候被排进队列的这里有一个容易被忽略的细节await async2()执行async2时async2内部如果没有任何await那么它会同步执行完console.log(async2)返回一个“已完成”的 Promise。紧接着await后面的代码作为微任务入队。但此时队列里还排着一个东西new Promise(...).then(...)的回调。等等那个.then回调是在什么时候排进队列的resolve()调用之后。那为什么promise2先于async1 end输出因为.then回调是在同步执行resolve()那一刻就排队了而await后面的代码是在async2返回的 Promise 状态被确认之后才排队。在 Chrome 的实现里await会额外产生一层微任务“包装”所以promise2排在async1 end前面。2.3 最容易失分的 Node 环境差异这道题如果再往下追问就会进入 Node 环境的差异区。Node.js 的事件循环和浏览器并非完全一致process.nextTick、setImmediate、Promise、setTimeout各有各的优先级。在 Node 的早期版本里process.nextTick的回调执行时机在“当前操作结束后的下一阶段之前”优先级比 Promise 的微任务还要高。而setImmediate则属于 check 阶段和setTimeout存在一个经典的“谁先谁后”的问题受事件循环的启动耗时影响并不总是稳定。能把这个差异讲清楚的人通常在 Node 服务端或工程化工具链上是有过实际经验的。不过这道题对纯前端岗位来说能讲清微任务、宏任务和渲染时机的关系就已经很够了。最有价值的延伸是浏览器会在一次宏任务和微任务处理完之后渲染之前有一个执行requestAnimationFrame回调的机会。如果候选人能提到“频繁操作 DOM 会阻塞渲染应该用 rAF 合并”这类实践那这题就拿得很稳了。2.4 为什么面试官反复考这道题事件循环几乎是所有高阶前端问题的底座。你聊性能优化绕不开渲染时机聊接口并发绕不开 Promise 的排队与竞争聊低代码平台的异步流程编排绕不开微任务队列的理解。面试官反复考这道题不是想让候选人背一套输出顺序而是想确认他脑子里的 JavaScript 执行模型是不是完整的。如果候选人能把执行顺序写对还顺带解释了“微任务队列要一次性清空”“宏任务和微任务是两个维度”这两件事我基本可以判断他对异步编程的上手速度会很快。因为日常开发里遇到的那种“明明先调用却后执行”的诡异 bug归根结底都长在事件循环这棵树上。3. Vue 响应式原理框架题答不好多半是没搞懂“拦截”二字3.1 高频追问v-model 究竟做了什么框架题是前端面试的另一个重头。不管简历上写的是 Vue 还是 React面试官都会挑一个高频 API 问原理。Vue 这边最常见的就是v-model。下面是“标准答案”v-model是语法糖。在组件上它等价于:value加input的组合在原生表单元素上它根据元素类型自动选择合适的属性和事件比如 input 用value加input事件checkbox 用checked加change事件。但这只是背诵版。面试官真正想听的是v-model的实现依赖什么底层能力答案就是响应式系统。表单元素的值变化后事件回调里把新的值同步给数据数据变化触发响应式更新视图重新渲染。没有响应式系统v-model只是空壳。3.2 从 Object.defineProperty 到 Proxy 的进化逻辑Vue 2 的响应式基于Object.defineProperty它在初始化时遍历 data 对象的所有属性为每个属性定义 getter 和 setter。这个方案的局限很明显新增属性不会自动变成响应式所以 Vue 2 才提供了Vue.set删除属性也不会触发更新所以有Vue.delete数组的索引赋值和 length 修改同样无法被拦截所以需要重写数组方法。Vue 3 的响应式用 Proxy 重构直接代理整个对象而不是逐个属性定义。新增属性、删除属性、数组索引赋值这些操作都能被捕获。这个升级不是“性能优化”而是从机制上补上了 Vue 2 响应式的系统性缺口。面试中有个很容易出彩的细节是Object.defineProperty是访问器属性的定义方式它本身是有语义限制的只能在初始化时静态定义。而 Proxy 是“代理层”可以拦截几乎所有基础操作。你把这层关系讲清楚再提到 Vue 2 的“重新赋值整个对象”“用数组方法代替索引赋值”这些常见规避手段面试官心里基本就有数了。3.3 diff 算法里的 key一个看似简单但经常答偏的问题另一道 Vue 高频追问是key 在 diff 过程中的作用是什么很多人会回答“为了复用节点提升性能”。这个说法没错但不够精确。key 的核心作用是通过唯一标识判断“同一层级中哪些节点是同一类型”从而跳过不必要的 DOM 创建和销毁直接走复用和更新的路径。但这里有个容易翻车的地方如果用数组 index 作为 key会发生什么问题比如一个列表删除第一项后后面每一项的 index 都变了key 和真实数据不对应diff 时就会发生节点内容复用错乱典型表现是列表项的状态串了位。能主动补充这个反例的人说明真的经历过列表渲染的坑。diff 算法本身并不要求候选人都背下来但要知道它遵循的几条基本原则只比较同一层级tag 和 key 都相同才复用组件类型不同直接替换。把这些说清楚已经能证明对框架渲染流程有系统认识。3.4 框架题的答辩策略给一个我实际面试中很受用的建议框架题不要只讲 API 是怎么用的尽量往下挖一层。比如问到兄弟组件通信不要只报“事件总线、Vuex、Provide/Inject”这几个名词而是可以挑一个展开Provide/Inject 在跨层级注入时非响应式的问题怎么解事件总线在组件销毁时为什么要手动 off这些细节才是框架经验的分水岭。框架题里还有一个很常见的问题“Vue 3 为什么更快”回答要避免只聊 Proxy 一个点。Composition API 的静态分析优势、模板编译器的优化静态标记、事件缓存、PatchFlag按需更新的机制都是重要支点。能讲到 PatchFlag 的人基本可以确认是看过源码级资料或者在项目里做过性能分析的。4. 从输入 URL 到页面渲染全链路题怎么回答才不显得背稿4.1 经典题目的“分阶段回答”框架“从输入 URL 到页面展示中间发生了什么”这是一道足以考察完整知识体系的题也是简历上写着“了解浏览器渲染原理”的候选人最容易暴露水平的一道题。我建议答题时明确分成四个阶段网络请求、解析构建、渲染绘制、资源加载。如果候选人一上来就背“DNS 解析TCP 连接HTTP 请求……”而不给任何阶段划分我会觉得他对整条链路的掌握是线性的没有形成结构。分阶段的好处是你可以每说完一段就停一下观察面试官对哪一段感兴趣然后主动展开。比如说到网络请求可以补一句“如果资源命中了缓存这里可以跳过 HTTP 请求”面试官顺着问缓存策略你就顺势把强缓存、协商缓存都讲一遍。4.2 每一段里藏着哪些性能优化点这道题是性能优化问题的入口几乎所有优化点都能在这条链路上找到落脚处DNS 阶段dns-prefetch可以提前解析域名TCP/TLS 阶段HTTP/2 多路复用和连接复用能减少握手开销HTTP 请求阶段静态资源加 CDN、开启 gzip、配置强缓存和协商缓存HTML 解析阶段CSS 放头部、JS 放底部或者用defer/async渲染阶段减少 DOM 层级、避免强制同步布局、对高频事件做防抖节流如果候选人在回答链路的过程中能顺手把性能优化点编织进去说明他不只是背了知识点而是真的拿优化工作“反推”过渲染全过程。这种答题方式非常加分。4.3 面试官追问的常见分支这道题的追问方向非常多我一般会挑两三个典型的。第一个追问是CSS 会阻塞 DOM 解析吗答案是不会阻塞 DOM 解析但会阻塞渲染。浏览器构建 DOM 树和 CSSOM 树是两条流程CSS 加载会延迟 CSSOM 树的构建进而阻塞渲染树生成。但如果后面有一个 script 依赖了 DOM 和样式情况会复杂一些。这里能展开到“script 为什么可能等待 CSS 加载”的说明对浏览器渲染流程有较深理解。第二个追问是defer和async的区别是什么defer是“下载完等 DOM 解析完再执行”多个defer脚本保持执行顺序async是“下载完立即执行”顺序完全不保证。这个细节直接对应“为什么 jQuery 时代推荐把 script 放在 body 末尾而现在可以用defer把 script 放到 head 中”的实践变迁。第三个追问更偏实战长列表滚动卡顿你会从这条链路的哪个环节排查这个问题的要点在于长列表卡顿基本不是网络问题而是渲染和绘制阶段开销过大常见方向包括DOM 元素过多导致布局时间变长、滚动过程触发强制同步布局、重绘区域过大。对应的优化是虚拟滚动、will-change合理使用、样式批量变更。能把这题重新映射到渲染链条的候选人通常也是做性能优化做得比较多的。4.4 如何用个人项目经验反哺答题碰到全链路题我最喜欢的候选人反应是在回答完标准链路后主动补一句自己项目里的真实经历。比如“我们之前做数据大屏首屏有几十个图表组件一开始接口加载和渲染都在主线程里跑首屏能等好几秒。后来我们拆成数据请求优先、图表组件懒加载、图表库按需引入首屏时间降了 60% 左右。”当候选人把链路知识和自己的项目串起来了说明这些知识不再是考卷上的东西而是已经被验证过的工具这个信号比答对任何一道题都重要。5. 项目深挖与开放设计题面试官真正在听什么5.1 一个典型的前端监控设计题技术面进行到后半段面试官常常会抛一道开放设计题。这种题没有标准答案但我见过不少候选人在这类题上答得比基础题还差原因不是技术不懂而是“没有设计框架”。举一个我常用的题如果让你给公司前端项目设计一个监控系统你会怎么设计这个问题考察的范围非常广采集哪些指标JS 错误、资源加载失败、接口成功率、页面性能、怎么采集错误事件监听、Performance API、MutationObserver 监听白屏、怎么上报图片打点、sendBeacon、怎么聚合和展示按页面、按版本、按浏览器维度。候选人如果能按“采集-上报-存储-展示-告警”五个环节分步展开即使某些环节没有实操过这个回答也是合格的。5.2 回答开放题的四种思维框架给一个特别实用的建议开放题不要想到哪说到哪先套一个框架再填充细节。下面这几个框架是我自己面试时比较认可的。第一种是“生命周期”框架。从用户操作开始到请求发出、数据处理、界面更新、异常兜底按完整的业务链路组织答案。监控系统的设计就适合用这个框架。第二种是“分层架构”框架。把系统拆成接入层、逻辑层、存储层、展示层一层一层往下聊适合答“如何设计一个组件库”“如何设计权限系统”这类题。第三种是“需求-实现-验证”框架。先说清楚要解决什么问题再说怎么实现最后说怎么确认问题被解决了。这个框架适合答“如果给你一个旧项目你第一周会做什么”这类偏规划的问题。第四种是“横向对比”框架。比如“微前端方案选型”这种题可以用 qiankun、micro-app、module federation 做横向对比从技术原理、接入成本、生态成熟度三个角度展开。框架本身不产生答案但能让你在高压面试环境下保持输出有序这一点在实战中很管用。5.3 如何在项目描述里主动埋钩子开放题答得好不好不仅取决于现场发挥还取决于你简历里的项目描述写得怎么样。我发现一个普遍问题很多候选人简历里的项目写成了功能列表——“负责订单模块开发、负责权限系统改造”但完全没有给面试官留“追问入口”。聪明的写法是主动埋钩子比如“针对订单模块首屏耗时 4 秒的问题做了组件懒加载和首屏数据并行请求首屏耗时降到 1.8 秒。”面试官看到这句话大概率会追问“你是怎么定位到首屏问题的”“懒加载在什么场景下会失效”这些问题在你准备范围内你就可以把对话节奏控制在自己手里。5.4 复盘这套回答逻辑同样适用于手写题前面聊了这么多其实都指向一个核心逻辑面试官不是要一台“人形题库查询机”而是一个能理解系统、解决问题、表达清晰的同事。这套回答逻辑同样适用于手写题。比如手写一个防抖函数如果候选人只写出完整代码我可能会继续追问“防抖和节流的适用场景怎么区分”“immediate 参数要控制什么”。如果候选人能在代码里主动给边界条件写好注释比如“这里要保留 this 指向”或者“定时器 ID 要用变量保存”那实际上就已经完成了一次设计表达。面试中的“专业感”其实就是这些细节叠加出来的。不是每一道题都要答得完美但每一道题你都要让对方感受到你不只是见过这个题的答案而且动手写过、踩过坑、知道它为什么存在。这也是《前端专业面试真题》这个系列里我最想传递的东西。最后再分享一个我自己的小习惯每次面试完我都会把候选人某个答得特别清晰的思路记下来哪怕只是一个比喻、一个切入角度。积累久了你会发现真正好的技术表达往往不在教程里而在这些真实对话中。准备面试和做面试官一样保持输入和复盘才是持续进步的方式。