企业官网建设流程全解析

面试官视角下，高级前端开发工程师面试题的正确打开方式

每年金三银四、金九银十，我作为公司技术负责人都会参与几十场前端岗位的面试。看得多了，反而对市面上流传的各种“面试题合集”感触很深：很多候选人刷题确实很猛，能流畅背出定义，但一追问原理、一深挖项目就露馅。而我自己出题时，最在意的不是“你背了多少题”，而是“你能不能把知识点讲透、能不能在工作里真正用起来”。

这份高级前端开发工程师面试题，是我在带团队、做面试官的过程中逐步整理出来的。部分题配了参考答案，但更重要的是我加了“追问思路”和“答法分析”，因为面试官问一道题，从来不是为了听标准答案，而是想通过这道题看你的思考方式、知识体系、沟通表达和工程判断。适合三类人：准备跳槽的高级前端、想带团队或面试别人的技术负责人、以及想系统查漏补缺、从初中级往前端专家方向走的同学。

先说一个我反复观察到的事实：很多人觉得自己工作三五年就能对标“高级前端”，但真正面试时，往往连一道“闭包与内存”相关的基础题都答不透。所以别嫌题简单，也别怕题偏，先把这套题真正吃透。

1. 面试官视角：高级前端面试到底在考什么

我在给公司设计面试流程时，从来不按“八股文题库”去机械打分。高级前端岗位的核心判断维度有三个：第一，语言功底是否扎实，这里说的不是背语法，而是对 JavaScript 核心机制的理解程度；第二，框架和工程化是否形成了体系，能不能讲清原理而不只是会写业务；第三，面对开放性问题时，能不能像“带过项目的人”一样做技术选型和取舍。

所以你会发现，这套面试题里几乎没有“纯背诵题”。比如问你“闭包是什么”，这题太重背诵，我通常不会直接这么问。我会给一段代码，问你输出什么、为什么、如果改成 let 会怎样、如果加上 setTimeout 又怎样——这种题才能区分“看过书”和“真懂”。再比如问你“nextTick 原理”，很多人背得出“微任务优先”几个字，但一问为什么要配合宏任务、DOM 更新在哪个节点完成，就答不上来。这就是理解和记忆的区别。

另外，面试官的选人逻辑也有一个共性：我们不喜欢“什么都会一点”的人，但喜欢“基础极牢 + 有深度方向”的人。所以这套题分成语言基础、框架原理、工程化、性能优化、手写实现、场景设计六大块。每一块后面我都会标出“面试官想听到什么程度”，你在准备时也能有一个明确坐标。刷题不是背答案，而是通过题去重新审视你自己日夜写的代码。

2. 核心必考：JavaScript 语言能力题精选（附参考答案）

2.1 手写 call、apply、bind：this 指向、闭包与原型链的综合考察

面试官问：请手写一个 call，并说明与 apply、bind 的区别。

这道题考察密度很高。先说参考答案核心：call 的关键是利用“谁调用函数，this 就指向谁”的规则，把 target 函数临时挂到传入的 this 对象上执行，再删掉它。经典实现如下：

Function.prototype.myCall = function (context, ...args) { if (context === null || context === undefined) { context = globalThis; } else { context = Object(context); } const key = Symbol('key'); context[key] = this; const result = context[key](...args); delete context[key]; return result; };

这里有几处容易被忽视的细节：用 Symbol 作为 key 是为了避免和原对象属性重名；context 为 null 时严格模式下和普通模式下行为不同，答题时提一下 “严格模式下 this 不被包裹、非严格模式下会指向全局”就能加分；apply 只是参数传法不同，bind 则返回一个新函数且可以被 new。

我个人的答题建议是：手写实现只占 30% 的分，真正决定面试结果的是你的讲解。你要主动说清楚“为什么函数内部 this 是动态绑定的”“为什么箭头函数没有自己的 this”“bind 后加 new 会发生什么构造行为”。这些追问如果都能接住，基本就是满分回答。实际面试中至少有三分之一的候选人写不对 Symbol 那一步，因为平时几乎不用 Reflect 和 Symbol 这类 API。

2.2 经典循环与闭包陷阱：不只是输出 0-5 的问题

面试官问：下面代码输出什么？如何让它正常输出 0、1、2、3、4、5？

for (var i = 0; i < 5; i++) { setTimeout(() => console.log(i), 1000); }

表面答案是输出 5 个 5，原因是 var 声明的 i 属于全局函数作用域，循环结束后 i 已经是 5，而回调函数被 scheduler 排队执行时会去共享的变量环境里读取 i。但高级答题不能停在这里，至少还要补充三种修复方式和各自的原理：

• 用 let 声明 i，让每一轮循环进入一个新的块级词法环境，回调闭包捕获的是每轮独立的 i。
• 用 IIFE 把 i 作为参数传进去，用“副本值”打破共享。
• 把循环体改成 for...of 配合 const，因为每次迭代都会产生独立绑定。

面试官经常继续追问：如果把 1000 改成 0，输出变不变？其实不管延迟是 0 还是 1000，输出结果都一样，因为 setTimeout 属于宏任务，必须等当前调用栈清空后才执行。真正改变结果的，是把这段代码放进 async 函数里并且前面有 await，或者用 Node.js 环境下的 process.nextTick 改变排队顺序。追到这里，已经能看出候选人事件循环的掌握深度了。

2.3 防抖与节流：高频面试题背后的性能本质

防抖和节流为什么是面试高频题？因为它们在生产里的使用场景太密集了：搜索联想、窗口 resize、滚动加载、表单实时校验。防抖追求“最后一次执行”，节流追求“固定频率内的有效执行”。手写代码不复杂，但面试官真正想看的，是你会不会忘记“首次触发是否立即执行”这个隐藏需求。

function debounce(fn, wait, immediate = false) { let timer = null; let invoked = false; return function (...args) { if (timer) clearTimeout(timer); const callNow = immediate && !invoked; if (callNow) { fn.apply(this, args); invoked = true; } else { timer = setTimeout(() => { fn.apply(this, args); invoked = false; }, wait); } }; } function throttle(fn, interval) { let last = 0; return function (...args) { const now = Date.now(); if (now - last >= interval) { last = now; fn.apply(this, args); } }; }

注意，我写的 debounce 多了一个 invoked 状态，这是实战中的常用变体：需要首次立即触发一次，然后进入防抖等待周期。很多面试者现场写不出这个细节，或者写的 throttle 用的是 setTimeout 版本，其实两种都可以，但你最好能说清楚基于时间戳版本可能导致 trailing 漏触发，基于定时器版本可能导致 leading 不触发。如果在回答最后补一句“用 underscore/lodash 的版本里还支持 cancel 方法”，会让面试官觉得你真的在项目里处理过这类细节。

2.4 深拷贝与浅拷贝：从数据不可变到序列化陷阱

这道题不管面初级还是面高级都会出现，但不同级别要求完全不一样。初中级能写出递归遍历对象就算过关，高级至少要踩完整整五个坑：Date、RegExp、Map、Set、循环引用、函数与 undefined 的序列化丢失。

参考答案重点是循环引用处理，用一个 WeakMap 保存已拷贝的对象引用，遇到同一对象直接返回，避免死递归。另外千万别用 JSON.parse + JSON.stringify 当万能解，因为 Date 会被转成字符串、函数和 undefined 会被直接丢弃、RegExp 会变成空对象、Symbol 作为 key 会被忽略。我见过太多候选人张口就是这个办法，让人觉得项目里没有真正处理过复杂数据结构。

如果你还想展示工程经验，可以提一提“结构化克隆算法”，浏览器 postMessage 底层和 Web Worker 传递数据用的就是它，比手写深拷贝覆盖的类型更全。高级前端不要求你把深拷贝做到 lodash 全量水平，但你要能说出边界情况，并且知道什么场景下需要“浅拷贝 + 不可变数据更新”的思路来替代深拷贝，因为在 React 生态里，深拷贝大对象往往意味着没必要的重渲染，开发中更应该用小工具实现局部不可变更新。

3. 框架与原理：Vue、React 核心机制的追问难在哪里

3.1 响应式系统的核心链路：依赖收集与派发更新

框架题里，Vue 的响应式原理是绝对绕不开的。大多数面试者都会说“Vue2 用 Object.defineProperty、Vue3 用 Proxy”，但接下来一句就卡住了——你知道依赖收集发生在哪一步吗？为什么视图更新要放到 nextTick 里？

我梳理了一条完整链路，面试时如果你能按这个顺序讲清，基本稳了：

• Vue2 在组件初始化时遍历 data 对象，给每个属性递归添加 getter/setter。渲染函数执行时，模板用到的 data 属性会触发 getter，当前 watcher 会被收集进该属性的 Dep 里，这叫依赖收集。
• 数据变更时 setter 触发，通知 Dep 里所有 watcher 执行 update，watcher 不会立刻更新页面，而是进入调度队列，在 nextTick 里批量统一更新，这叫派发更新。
• Vue3 用 Proxy 拦截对象操作，天然支持新增属性、删除属性、数组监听，不需要 $set，同时用 WeakMap 存储每个对象的依赖结构，避免 Vue2 里 Dep 和 Observer 与原始对象耦合的问题。

参考答案说完了，但我一定要额外提醒：面试官问 Vue 响应式，往往真正想听到的是“你对发布订阅模式的理解”。Vue 的响应式本质上是多对多的发布订阅系统，依赖收集就是“订阅关系建立”，派发更新就是“广播消息”。如果你能把这个模式抽象出来，再类比说 EventBus、Redux 的 store 通知、甚至 Node.js 的 EventEmitter，都在做同一件思想层面的事，说明你不是单纯背书。

另外有一点容易踩坑：面试官如果问 Vue3 为什么用 Proxy，正确回答不仅要说“支持动态新增属性、性能更好”，还要补一句“Proxy 是惰性代理，访问到哪个属性才拦截哪个属性，没有预先递归所有属性的初始成本”。Vue3 的响应式系统是 lazy 的，Vue2 是激进递归的，这个区别很能体现源码阅读深度。

3.2 虚拟 DOM 与 diff 算法：为什么不用真实 DOM？

虚拟 DOM 的面试难度级联比较强，初级问“是什么”，中高级问“为什么快、快在哪”，真正的高级追问是“既然有 diff，为什么 React 还是推荐用 key？什么副作用会让 diff 优化失效？”。

要回答得彻底，先想清楚一个问题：操作真实 DOM 慢，不是慢在创建节点，而是慢在触发布局、绘制、合成这些浏览器渲染管线。虚拟 DOM 是在 JavaScript 里模拟一棵节点树，通过 diff 找出最小变更集，最后一次性集中更新真实 DOM。它快在“把多次零散的更新批量化、把代价高昂的重排重绘次数压下来”。

diff 的核心假设是“同层比较、类型不同直接重建、通过 key 进行复用”。面试官问 diff 算法，不是希望你背出 O(n) 的时间复杂度怎么推导，而是希望你明白两件事：第一，为什么只比较同层节点，因为跨层级移动 DOM 在实际业务里极其罕见，做这个取舍就能把复杂度从 O(n^3) 降到 O(n)；第二，key 的存在让列表更新可以用“移动节点”代替“销毁重建”，但如果你用数组 index 当 key，当列表顺序变化时，React 可能复用错误的组件状态，导致输入框内容错位。

最后可以答一个很多人不知道的点：Vue3 的 diff 在编译阶段就走得更远，会把静态节点标记成静态提升，把动态绑定的节点标记出具体动态字段，这样 patch 过程可以跳过大量静态内容。React 也在做编译期优化，但 Vue 的双层优化思路更彻底，这才是框架竞争里值得聊的有价值话题。

3.3 组件通信与状态管理：props、事件总线与 Pinia/Redux 的边界

“业务里组件越来越多，状态越来越乱，怎么办？”这是真实的业务问题，面试官当然也要问。常见答法是把 props 传递、$emit/自定义事件、provide/inject、EventBus、Vuex/Pinia、Redux 列一遍。能列出来是 60 分，高级回答要明确边界：

• 局部状态用组件自己的 data/ref，多层级浅更新用 provide/inject 或 React Context。
• 跨组件高频事件用事件总线在小型项目里很方便，但它最大的问题是“不好追踪、难以调试、模块间隐式耦合”，项目大了你根本不知道谁监听了这个事件，风险非常高。
• 真正的全局共享、需要跨页面持久化、需要配合 DevTools 时间旅行的场景才适合上状态库。实际上我面试时还会追问一个业务问题：“如果你有一个倒计时状态，多个页面都要显示，但要求刷新之后还能继续数，你会怎么设计？”正确答案不是把自己锁死在某个状态库里，而是“持久化存储 + 服务端时间校准 + 客户端自动续跑”的组合方案。

我在实际项目里的原则是：状态管理库不要用来承载所有数据，只承载“真正的全局共享更新”部分。页面 A 用了一个字段、页面 B 也用，但如果它们之间不需要联动更新，那它其实就不该放在全局 store 里，本地存储加读取就够。很多项目代码里的状态库被塞入成百上千个字段，最后每次改动都牵扯不清，其实不是工具的问题，是使用者没有做好状态边界划分。

3.4 组件的渲染机制：为什么不应该在渲染函数里做昂贵计算

问到组件优化，很多候选人能说出“不要在 render 里写复杂逻辑”，但追问一个“为什么”就沉默了。原因其实和函数式编程的执行时机有关：render/函数组件的 render 阶段执行频率远高于你想象的，任何状态更新都可能导致重新执行 render，如果你在 render 过程里做了大量计算、创建了新数组、调用了不稳定的高阶函数，会直接阻塞主线程。

高级面试题里往往会出这种场景：“一个列表有 1 万条数据，每条数据都要根据某个字段做格式化，还要根据另一个字段排序，你怎么优化？”参考答案要分几层：第一，数据预处理，一次计算好格式化和排序结果，不要每次渲染都重新算；第二，列表虚拟化，只渲染可视区节点，1 万条实际渲染几十条；第三，用 useMemo/computed 缓存结果，依赖项不变就直接返回缓存。最后补一句“频繁变化的字段单独抽出来高频刷新，低频稳定的内容整块缓存”，这种工程细节才是高级工程师和初级开发的分水岭。

4. 工程化与性能优化：高级前端面试题的硬核部分

4.1 模块化演进与打包原理：CommonJS、ESM 与 Tree Shaking

工程化题最不容易背，因为直接和你的日常构建经验挂钩。面试官通常这么问：CommonJS 和 ES Module 有什么区别？Tree Shaking 是怎么实现的？为什么有些库打了 tree shaking 还是没有效果？

参考答案核心：CommonJS 是运行时加载，同步执行，module.exports 是一个对象，加载后如果需要更新只能重新赋值；ES Module 是编译时静态分析，import 必须是顶层声明，所以构建器可以从 import 语句精确知道引入了哪些命名导出，从而把没用的代码在打包阶段消除，这就是 Tree Shaking 的前提。

为什么有的库 tree shaking 失效？常见原因包括：使用了具有副作用的顶层代码，比如给原型打补丁或者有全局注册的 CSS 引入；package.json 里缺少 sideEffects 字段标记；打包器无法确定导入是否纯净，保险起见全部保留；或者是 CJS 格式的库，因为整个模块被当成一个动态对象加载，无法静态分析。这就是为什么现在很多组件库都会同时给 ESM 和 sideEffects 配置，尽可能帮助打包器做摇树优化。

我强烈建议你把 Webpack/Vite 构建产物的分析图看一次，比如用 source-map-explorer 打开打包后的文件，你会直观看到哪些库占了多少体积、哪些代码根本没被用上却被打进来了。这种“动手看产物”的能力，比背十道打包原理题都更能让面试官信服。

4.2 缓存策略与加载优化：从强缓存到资源指纹

性能优化题里，缓存是性价比最高的一类，因为它和技术栈无关，但很少有候选人能答全。面试官问：浏览器缓存体系是怎么工作的？强缓存和协商缓存的区别是什么？

参考答案大概这样：强缓存由 Cache-Control 控制，常见值有 max-age、no-cache、no-store。max-age 期间浏览器不再发请求，直接取本地缓存；no-cache 的意思是“可以缓存，但每次都要去服务器验证”，不是“不缓存”；no-store 才是真不缓存。协商缓存常用 Etag/Last-Modified，资源过期后来不及等都走服务端验证，304 则代表资源未变化。

高级部分要结合前端工程化讲：为了让静态资源能安全长期缓存，打包时要在文件名里加上 hash 指纹。内容变化 → hash 变化 → 文件名变化 → 浏览器自然请求新文件；内容不变 → hash 不变 → 可以放心设置 max-age 很大（比如一年），旧资源永远命中强缓存。这里有个实操技巧：HTML 本身不要设置长缓存，一般用 no-cache，因为它是入口文件，需要每次验证；而 JS/CSS/图片这类带 hash 的资源，才适合 max-age 一年。很多项目优化忽冷忽热，其实就是把 HTML 也包括了长缓存，发布新版本后用户还一直看到旧页面。

4.3 渲染性能指标与优化手段：70 分的 FCP 用户仍然可能觉得卡

性能题如果再往上拔一层，面试官就会问你“怎么衡量性能”。这里说的是用户体验层面，不是开发者工具里的 Network 面板。你要正确分清几个指标：FCP（首屏内容绘制）、LCP（最大内容绘制）、FID（首次输入延迟）、CLS（累计布局偏移）。

深入答题时，至少要能说出一个完整的性能问题排查流程：先用 Lighthouse 跑一次体检，拿到核心指标分数，再用 Performance 面板录制一段交互操作，观察 Long Task、重排重绘、以及主线程被阻塞的区间，最后用 Network 看资源加载瀑布流找出阻塞项。给用户优化时，常见手段有三个：减少阻塞渲染的脚本，比如把非关键 JS 加 defer 或动态 import；压缩首屏请求体积，优先保障 LCP 资源尽快加载；用图片懒加载和 content-visibility 减少首屏外的渲染成本。

我复习时会把这几个指标的关键词抄在卡片上反复问自己：LCP 是“最大”，FID 是“第一次交互延迟”，CLS 是“视觉稳定性”。记忆容易混的人可以先想想用户感知：打开一个页面感觉要白屏很久 → FCP 不行；等了一会儿内容刷出来但核心图片迟迟不出现 → LCP 有问题；点按钮没反应 → FID 有问题；页面加载完成但文字跳来跳去 → CLS 报警。性能优化的答案一旦能和用户体感挂钩，面试官立刻知道你真的在线上处理过问题，而不是背了指标定义。

4.4 安全问题：前端面试里最容易忽略但面试官一定会问的版块

高级前端面试常见的安全题包括：XSS 是什么？CSRF 是什么？如何防御？除了经典 CORS 判断题和内容安全策略之外，有些高级场景题也值得预先准备，比如“第三方脚本被注入后，你如何尽量限制它的危害”。

参考答案：XSS 的核心是“未过滤的用户输入被当作 HTML/JS 执行”。防御手段有三层，输入侧转义、输出侧编码、兜底 CSP；CSRF 的核心是“攻击者借用浏览器自动携带 Cookie 的特性伪造请求”。现代项目防它优先用 SameSite=Lax/Strict Cookie，再配合自定义请求头校验或 CSRF Token 双重验证。CSP 的正确配置方式是设置白名单源，让浏览器拒绝加载白名单之外的脚本和样式，即使攻击者注入成功，也没有外联脚本可以执行。

回答安全题的目标不是“全对”，而是“能持续考虑攻击面”。高级前端离不开安全意识，如果一个候选人聊到登录状态管理时完全没想到 Token 的存储位置、没想过 XSS 后 token 会被窃取，那他在团队里大概率是埋雷的人。

5. 手写代码题：面试现场的实战演练

5.1 关于手写题，面试官真正想观察什么

手写题考察的不是记忆，而是两件事：你在高压环境下的建模能力和编码习惯。我自己面试时如果让候选人手写一个 Promise.all、防抖节流或者发布订阅，我打分看的维度一般是：命名是否清晰、边界和异常是否考虑、代码是否直接可用。

所以送你一条非常重要的实战建议：不要背题，而是背“建模框架”。先告诉自己“这是一个函数，输入是什么、输出是什么、异常怎么处理”，再动笔。比如面试官让写一个深拷贝，你先说“目标是返回一个独立数据结构，输入可能是普通对象、数组、Date、Map、循环引用”，这个过程本身就是一种思考展示，好的面试官会顺着你的思考补一句“很好，那循环引用呢？”，你就自然进入下一层能力展示。

5.2 高频手写题汇总：从 Promise.all 到柯里化与发布订阅

这里给出我常考的几道高频手写题，以及我认为必须覆盖的关键点。

Promise.all：返回新 Promise，按输入顺序输出结果，任何一个 reject 则整体 reject，并且要处理空数组的情况。注意细节：需要用数组索引对应次序而不是 push，因为异步任务返回顺序不确定。

Promise.myAll = function (promises) { return new Promise((resolve, reject) => { if (!promises || typeof promises[Symbol.iterator] !== 'function') { throw new TypeError('not iterable'); } const results = []; let count = 0; if (promises.length === 0) resolve([]); for (let i = 0; i < promises.length; i++) { Promise.resolve(promises[i]) .then((value) => { results[i] = value; count++; if (count === promises.length) resolve(results); }) .catch(reject); } }); };

发布订阅（EventEmitter）：核心数据结构是事件名 → 处理器数组的映射，要有 on、off、emit，最好还要有 once。写这个题时，面试官追问最多的是 off 时数组遍历会不会有问题，如果你先 build 一个新数组再遍历，既安全又能避免迭代器边删边改的问题。

柯里化：核心是“收集参数，够了就执行”，要支持占位符版本就更进阶了。简单版是判断当前收集的参数数量是否达到原函数长度，达到了就 apply 执行，没达到就返回一个新函数继续收集。

function curry(fn, arity = fn.length) { return function curried(...args) { if (args.length >= arity) return fn(...args); return (...rest) => curried(...args, ...rest); }; }

5.3 手写 Vue 响应式或 React Hook 的简单版

这类题对高级工程师来说越来越常考。比如让你写一个 useDebounce 的 React Hook，考察你对 Hook 闭包陷阱的理解。参考答案：

function useDebounce(value, delay = 300) { const [debounced, setDebounced] = useState(value); useEffect(() => { const timer = setTimeout(() => { setDebounced(value); }, delay); return () => clearTimeout(timer); }, [value, delay]); return debounced; }

这里必须注意 useEffect 的清理函数返回值，每次 value 变化时都会先清理上一次的 timeout，再设置新的。如果不写清理，防抖完全失效，而且会变成“延迟后的多次更新”。回答时可以补充说：在这个 Hook 中，return 的 timer 清理函数是关键，所以 Hook 的依赖数组设计直接决定了理论的正确性。这一句比写代码本身更能体现你在使用 React 时的深度。

6. 从简历到面试现场：高级前端参与面试全流程的独门经验

6.1 简历筛选与技术面之间的隐形门槛

我不止一次看到很优秀的候选人简历上写着“精通 JavaScript”，但技术面第一题就翻车。这个问题的根源不是技术，而是简历的技能描述过于空洞，缺少让面试官可以直接提问的真实落点。写简历最推荐的做法是“一个亮点项目 + 三个数字化结果”。比如“主导了某中后台系统的前端重构，将首屏加载时间从 3.6 秒降到 1.2 秒，LCP 优化约 67%”，面试官顺着这个数据就能问出质量很高的问题，你也自然把面试节奏拉到自己擅长的区域。

相反，如果简历上只有“使用了 Vue/React/Webpack”这种罗列，我作为面试官只能随机选一道概念题试探，一旦正好踩中你的薄弱区，场面就会很尴尬。所以刷题之前先改简历，让简历替你过滤掉不期望的方向性问题。

6.2 技术面里最加分的表达方式：先结论，后过程，再分歧

很多候选人回答问题时喜欢从背景开始讲，讲了五分钟还没到重点，导致我完全抓不住他的逻辑。高级工程师的沟通方式应该像写代码一样结构化：先抛结论，再用一到两行的推导过程，最后说清楚边界和可能的替代方案。

比如面试官问“Vue2 和 Vue3 的 diff 有什么区别”，结论先行式回答是：“核心区别是 Vue3 在编译阶段做了静态提升和动态标记，所以运行时 diff 对比的范围更小、跳过更多静态内容；而 Vue2 是运行时全量对比，编译期优化有限。”然后你再展开。这种答法让我在十秒内就知道你有判断力，后面的展开只是补充细节，不管讲多深，方向的正确已经保底了。

还有一个细节：被问到自己不会的问题时，千万不要硬编。你可以很坦率地说“这个概念我了解得不深，但基于已有知识我推测它是……，另外我通常是通过查文档和看源码来补这块”。面试官并不是要求你全能，而是看你面对未知领域的姿态和学习路径。真诚加思路，往往比一个完全正确但干巴巴的答案得分更高。

6.3 深度追问期：面试官三道题连问的逻辑

我在面试时特别喜欢用“三道题连问”的方式考验候选人知识体系的牢固程度。典型套路是：

第一问：页面加载的完整链路是什么？（先测广度） 第二问：如果其中某个 JS 文件加载失败会怎么样？（测容错） 第三问：如果这个 JS 是第三方 SDK，失败了你如何让业务不受影响？（测工程方案）

如果你第一问能说出从浏览器解析 HTML、构建 DOM、发请求加载资源、执行脚本、触发渲染的完整链路，第二问马上考察你对模块加载错误与静态资源回退的理解，第三问则跳到“如何优雅隔离第三方脚本的失败影响”，比如给 script 标签加 Load 错误监听、动态注入资源后重试、或者用 Web Worker 隔离执行。能层层递进答完的人，在我这里通常直接进入“高级”档。

刷题一定要按这个“追问链”去准备，只要自己能对自己出一道题连续追问三轮不卡壳，面试基本问题不大。

6.4 最后的反问环节：高级前端面试官希望你问什么

面试流程最后，面试官通常会说“你有什么要问我的”。很多候选人问薪资、加班，可以理解，但站在面试官视角，我特别欣赏那些在反问环节展现思考深度的问题，比如“团队对前端性能监控是怎么做的”“如果入职，接下来半年的焦点项目方向是哪块”“团队的技术债主要在哪几个模块”。这些问题透露出你关心的是如何把手上的工作做成体系，而不是只关心个人得失。

反过来，我还是会提醒你：反问环节别问“咱们公司用什么框架”这类一查文档就知道的问题，也别问“加班多不多”这类稍微有点敏感的。比较好的做法是挑本场面试里一个你自己没完全答好的技术点，借机请教面试官“你们在实践中是怎么处理的”，这种“把面试变成技术交流”的姿态，往往能扭转前面表现略差的局面。

写在最后：一个问题，刷题到底要不要背

很多候选人问我，面试题要不要刷、该不该背。我的答案是：要刷，但刷的是“思考题”，不是“标准答案”。你可以拿这份清单做一次自我测评，每道题先停下来想三分钟，如果第一反应是空白，那恭喜你，这就是你下一个要补的知识点；如果你能自然讲出答案并且能回答我的追问，那你已经比大多数候选人准备得更充分。最后送你一句我作为面试官的真实体会：面试官要的不是一台“行走的八股文数据库”，而是一个看到问题能够拆解边界、能给出合理技术快择、并且知道自己在做什么的工程师。这套题，正是帮你往这个方向再靠近一步的路径。