1. 为什么前端面试必须“拒绝八股”
前端面试八股文泛滥这件事，行业里吐槽了好几年。Vue 的响应式原理、防抖节流的代码、浏览器从输入 URL 到页面展示的过程，这些问题本身没问题，但很多候选人背答案的痕迹太明显。你问他 nextTick 的实现原理，他能流畅讲完整个微任务队列；你给他一段真实业务代码，让他说出性能问题出在哪，他却愣住。
我面试前端工程师这几年，越来越确定一件事：背得熟的候选人好找，能做事的候选人难找。八股题只能筛出“记忆力好的人”，筛不出“能把代码写明白的人”。所以后来我调整了出题思路——所有题目都尽量带场景、带追问、带约束条件，让候选人现场推演，而不是复述。
这套 10 道题，就是我在多次面试中逐步沉淀下来的。它们覆盖 JavaScript 底层、浏览器渲染、Vue/React 框架、工程化、性能、异常排查、组件设计、技术重构这些前端工程师日常要面对的核心方向。适合三类人看：准备跳槽的前端开发者，可以用它做自检，看看自己的短板集中在哪个方向；负责招人的团队负责人或技术面试官，可以直接拿去改造成自己的面试题库；带新人的老工程师，也可以用它给组员做能力摸底。
要说明的是，这套题绝对不是“背诵型面试题”。有些题目看起来像八股，但真正考察的是候选人面对真实业务问题时的分析路径和取舍逻辑。我会把每道题的出题意图、参考思路、常见错误全部拆开讲清楚，你拿到手之后能直接用，也能根据自己的团队情况再改。
2. 10 道实战面试题全解析
2.1 第 1 题：异步代码执行顺序不再只考“背答案”
题目：写出下面这段代码的输出顺序，并说明原因。
async function test() { console.log('A'); await Promise.resolve(); console.log('B'); setTimeout(() => console.log('C'), 0); queueMicrotask(() => console.log('D')); } test(); setTimeout(() => console.log('E'), 0); Promise.resolve().then(() => console.log('F')); console.log('G');考察点：事件循环、微任务队列、宏任务队列、async/await 的执行时机。
这种题目如果只给一个 async 函数加 await，确实容易背。但我在里面加了queueMicrotask和多个定时器混在一起，候选人如果只是记住“微任务先于宏任务”这句话，大概率会栽在 B、D、F 的顺序上。
参考思路：代码先同步执行，输出 G，同时把setTimeout E放入宏任务队列。test()执行到await Promise.resolve()时，B 之后的代码被包装成微任务挂起，当前同步代码继续。所以 F 在await之后、B 之前触发。D 和 B 都是微任务，按入队顺序执行。C 和 E 都在宏任务队列，但 C 在 E 之前入队，所以先输出 C。
正确答案是：G → F → B → D → E → C。实际面试中，很多人会把 B 和 D 的先后搞反，还有人分不清queueMicrotask和 Promise.then 的优先级——其实它们在同一个微任务队列，按入队顺序执行。
这道题暴露的短板：对事件循环的理解停留在“微任务和宏任务”两个名词上，没有推演细节的能力。真实业务里，异步队列的顺序直接影响埋点上报、表单校验、批量提交这类功能的正确性。我面试时会故意追问一句：“如果这里改成await setTimeout呢？”能答上来的人才是真的理解了异步执行模型。
2.2 第 2 题：浏览器渲染时机，比“输入 URL 发生了什么”更实用
题目：页面里有一个同步<script>阻塞了首屏渲染。脚本执行后，用setTimeout(() => { box.style.transform = 'translateX(100px)' }, 0)修改元素位置，同时用requestAnimationFrame也修改了一次。用户最终看到元素移动了吗？哪个先触发？为什么？
考察点：渲染管线（布局、绘制、合成）、requestAnimationFrame 与 setTimeout 在渲染中的位置、主线程阻塞对渲染的影响。
老版本面试题常问“浏览器渲染流程”，候选人背熟了“解析 HTML、构建 DOM、布局、绘制”就能过关。但实际工程里，最常遇到的问题不是“原理是什么”，而是“为什么改了样式页面没更新”。这道题就是朝这个方向出的。
参考思路：同步脚本阻塞首屏渲染，脚本执行完后，主线程继续执行当前任务。setTimeout和requestAnimationFrame都在当前任务之后的“下一轮”触发，但 rAF 独特的地方在于——它会在浏览器下一次重绘前被调用，而 setTimeout 0 并不保证在渲染前执行。如果主线程忙碌，setTimeout 的回调可能推迟到本次渲染之后。所以用户可能看不到元素“瞬移”的过程，甚至如果 setTimeout 回调在渲染之后才执行，用户看到的是直接跳到了新位置。
这道题暴露的短板：90% 的候选人能把事件循环背得滚瓜烂熟，但问“rAF 和 setTimeout 哪个先更新页面”就卡住。因为他们的知识是分块的：事件循环归事件循环，渲染归渲染，从来没想过两者在运行时是交织的。实际做游戏、动画、滚动效果优化时，这个知识点非常关键。
我会这样追问：如果连续两次修改样式，中间不强制回流，浏览器合并更新吗？这能测出候选人是否真的知道“渲染合并”的机制。
2.3 第 3 题：Vue3 watchEffect 为什么“失效”了
题目：子组件从父组件接收一个对象userInfo，在子组件里需要根据userInfo.name的变化发起请求。你写成了这样：
watchEffect(() => { fetch(`/api/user?name=${props.userInfo.name}`); });父组件里做了一次userInfo.name = '张三'的修改，结果发现请求没有重新发出，为什么？
考察点：Vue3 响应式依赖追踪、watchEffect 的触发条件、对象属性修改与引用替换的区别、深浅响应式。
参考思路：watchEffect在初始化时立即执行一次，执行过程中读取了props.userInfo.name，所以它只追踪了这个字段的读取依赖。父组件直接修改userInfo.name时，如果userInfo是响应式对象，Vue 其实能感知到属性变化，但问题往往出在“userInfo 对象在父组件里根本做了非响应式的赋值”，或者props里的嵌套对象在传递过程中被解构，导致子组件里的userInfo不再是响应式的。另一个常见原因：父组件直接this.userInfo.name = '张三'，但在 Vue 3 的响应式机制下，对象新增属性或直接修改嵌套属性，依赖追踪已经能捕捉到了——所以这道题真正想听到的，不是“为什么不能直接改属性”，而是候选人能立刻想到去检查“这个对象到底是不是 reactive 的、是否经过 reactive 包装、是否存在 props 被解构的情况”。
这道题暴露的短板：很多候选人使用 Vue3 组合式 API 只是“照着模板写”，完全没有建立起响应式依赖追踪的心智模型。遇到 watchEffect 不触发，第一反应是去百度，而不是自己推演“这个 effect 被哪些变量依赖”。
实际业务里，这类问题最常见的场景是“从接口拿到的数据塞进一个普通对象，再传给子组件”——子组件里怎么 watch 都不会触发，因为数据根本不在响应式系统里。我会在面试中追问一句：“如果改成watch(() => props.userInfo.name, ..., { deep: true })能解决吗？”考察候选人能否区分 watch 和 watchEffect 在依赖追踪上的不同。
2.4 第 4 题：组件通信选型，考的是“判断力”而不是 API
题目：一个订单管理页面，左侧是订单列表组件，右侧是订单详情组件。两个组件相距很远，但详情组件需要根据列表组件选中的订单 ID 发起请求。项目里有人提议用 event bus，有人说一层层 props 传下去，有人直接要上 Pinia。你作为负责人怎么决定？
考察点：组件通信方案的选型依据、状态作用域分析、调试和维护成本、团队技术栈的合理使用。
这道题没有标准答案，但暴露的问题非常明显。候选人分三个层次：第一层次，只会背“props 向下、事件向上、不合适用 vuex”；第二层次，能分析当前场景：这个订单 ID 虽然跨两个组件，但它们的父级可以提供一个状态容器，用组合式函数或者 provide/inject 就能解决，没必要引入全局状态库；第三层次，会反问面试官：“这个订单 ID 只需要在当前页面内共享，还是多个路由都要用？是否需要刷新后恢复？团队对 Pinia 的熟悉程度如何？”——这就进入架构师思维了。
参考思路：核心是看状态的作用域。只在两个兄弟组件之间共享，最简单的方案是提升到父组件，或者用组合式函数封装一个模块级 state。不要为了省几行代码用 event bus，事件总线在大型项目里很难追踪数据流。也不建议一上来就引状态库，状态库放在“全局跨页面、跨模块”的场景更合理。
这道题暴露的短板：有的候选人只会“背方案”，遇到具体业务场景就无法把技术方案和成本挂钩。我面试时特别在意候选人会不会问“这个状态的变更频率是多少”“有没有多标签页同时操作”这类问题——能问出来的，才是真正处理过复杂业务状态的人。
2.5 第 5 题：打包体积优化，考的是“排查思路”不是插件清单
题目：公司内部后台管理项目，Vite 构建产物里 vendor chunk 有 2.4MB，首屏加载要 6 秒。你手上有一个dist目录和构建环境，怎么开始分析和优化？
考察点：性能分析工具链、构建产物拆解思路、gzip/brotli 压缩、CDN 和 external 策略、按需加载的落地手段。
参考思路：正确的动作顺序是——先量化，再拆解，最后动手。第一件做的事是看构建报告，Vite 项目用rollup-plugin-visualizer，Webpack 项目用webpack-bundle-analyzer，确认 2.4MB 具体由哪些包贡献。很多候选人一上来就说“用 CDN 引入 vue”，这暴露了一个大问题：他连“vendor 里到底是什么占大头”都没确认，就急着开药方。
拿到报告后，常见的优化路径包括：把 echarts、ant-design-vue 这类体积大的库改成按需引入；检查是否把整个 lodash 打包进去了；业务组件做路由懒加载；开启自动拆包，把 node_modules 里体积超过阈值的大包单独拆出来利用缓存；最后再考虑 CDN 和 external 排除稳定依赖。
这道题暴露的短板：
- 只说“配置 splitChunks”但讲不清拆包规则怎么定；
- 不知道 gzip 的收益有多大，或者把 gzip 当成优化唯一手段；
- 没意识到首屏加载慢和“页面业务逻辑复杂”是两件事，需要区分网络传输时间和 JS 执行时间。
我会在现场让候选人画一下他常用的构建流程，再加一个追问：“拆包拆多了也会有问题，你拆包的原则是什么？”能说到“缓存命中率、请求数量和并行度平衡”的候选人，工程化经验基本靠谱。
2.6 第 6 题：首屏性能现场题，直接看 Network 面板
题目：下面是某个页面首屏加载时 Network 面板的部分数据描述：
- HTML 文档下载耗时 800ms 才开始返回（TTFB 高）
- 一个渲染阻塞的 CSS 文件下载耗时 2.4s
- 页面共发起 14 个同步请求
- Lighthouse Performance 得分 48
请你说出三个最可能的问题点，以及你验证和修复的优先级。
考察点：性能问题定位的优先级思维、渲染阻塞资源的判断、请求数优化、缓存策略。
参考思路：第一个要盯的是 TTFB，HTML 都要等 800ms 才返回，说明服务端响应或网络链路有问题，这个不解决，后面所有优化都被放大。第二个是那 2.4s 的 CSS 文件，它是渲染阻塞资源，CSS 没下载完页面不会渲染，需要看这个文件是不是重要，考虑拆成关键 CSS 内联、非关键 CSS 异步加载。第三个是请求数，14 个同步请求说明存在大量串行依赖，先合并接口还是先做缓存，要看接口之间的依赖关系。
这道题暴露的短板：很多候选人没有“性能问题有优先级”的概念，一上来就提“图片懒加载、加 CDN”——这些是优化手段，不是排查思路。真正的优秀候选人会从瀑布图读起，先判断“哪个瓶颈是路径上的关键节点”，再决定动哪儿。
我会这样追问：如果 CSS 文件已经加了 CDN，但 TTFB 还是高，你觉得可能卡在哪个环节？候选人能否说出“DNS 解析、TCP 连接、服务端处理、后端接口慢”这一层层往下拆，就能看出他有没有真实处理过线上性能问题。
2.7 第 7 题：大文件上传，从并发控制到 Worker 计算
题目：你要做一个大文件上传功能，文件可能 5GB 以上。前端需要处理切片、计算文件 hash、控制并发上传、支持失败重试。请画出整体流程图，并手写一个最简单的并发调度器——限制同一时刻最多 3 个上传请求。
考察点：并发控制、文件切片、Web Worker 的使用、内存管理、错误重试策略。
这道题结合了工程实践和手写能力。文件切片时，候选人最容易忽略的问题是“把整个文件读进内存再切”，5GB 文件这样操作浏览器直接崩溃。正确做法是用Blob.slice()按偏移量切片，然后逐片读取上传，但 hash 计算要跑整个文件，这个过程如果放在主线程，页面会卡死，所以要用 Web Worker 来算 hash。
参考思路：并发调度器核心是维护一个“进行中任务池”，达到上限时把新任务放入待执行队列，任一个任务完成后，从队列取下一个。伪代码思路如下：
async function runWithLimit(tasks, limit) { const results = []; const executing = new Set(); for (const task of tasks) { const p = Promise.resolve().then(() => task()); results.push(p); executing.add(p); p.finally(() => executing.delete(p)); if (executing.size >= limit) { await Promise.race(executing); } } return Promise.all(results); }这里有几个隐藏考点：
Promise.race的用法是否正确，有没有及时清理已完成的任务；- 失败重试怎么做——不能无限重试，要设最大次数和退避间隔；
- 切片的上传进度如何汇总展示；
- 断点续传需要后端配合，前端要记住哪些切片传过了。
这道题暴露的短板：写不出调度器的人，不一定是不会 API，而可能是平时根本没处理过并发场景。还有候选人会把“并发限制”直接做成“分批串行”，那样没法利用带宽，也不是真正意义上的并发控制。
2.8 第 8 题：线上白屏，你只有监控数据，怎么定位
题目：线上用户反馈“打开某个页面一片空白”。你的监控平台上现在只有以下信息：一个 JS 报错堆栈（压缩过的）、用户操作系统和浏览器版本、上报时间戳。你还有发布系统的权限，接下来你会做什么？
考察点：前端异常处理、错误监控体系、sourcemap 还原、版本回放思路、复现路径。
参考思路：第一步是用 sourcemap 还原压缩后的报错堆栈，这一步很多团队没做，导致线上报错根本看不懂。第二步是看报错时间点对应当前线上的版本号，如果发布记录里那个时间段有上线动作，优先怀疑新版本回归。第三步是尝试复现，用相同的浏览器版本和用户路径走一遍。
真正有经验的人会多说一步：用户能正常打开其他页面吗？是整站白屏还是单页面白屏？如果是 SPA 打包部署后路由切换引起的白屏，问题很可能出在historyApiFallback或者资源路径publicPath配置上。这几步走下来，已经不是一个“背监控 API”的面试题，而是完整的线上事故排查流程。
这道题暴露的短板：候选人只会说“用 Sentry”，但一问到 Sentry 上报的堆栈怎么定位到具体源码，就卡住了。还有人完全不提 sourcemap，直接把压缩后的报错丢给后端同事，这种处理问题的方式在职场上确实会出现。
我会追问：“如果还原堆栈时发现报错在第三方库内部，你怎么办？”候选人的答案要看是否沿着“升级库版本、找 workaround、排查自己代码调用方式”这条路走，还是在原地打转。
2.9 第 9 题：带搜索筛选和分页的列表组件，怎么设计才不“活不过半年”
题目：你要实现一个管理后台用户列表，包含关键词搜索、状态筛选、分页。产品要求：用户修改筛选条件后，点击某个用户进入详情页，返回列表时筛选条件、页码、滚动位置都要保留。你如何设计？
考察点：组件状态管理、URL 状态同步、持久化方案、列表缓存策略、交互细节。
这道题很贴近实际业务，而且每个候选人都会遇到类似需求，但设计水平差异巨大。初级答案：用ref存筛选条件，返回页面时恢复。这个方案的问题是刷新浏览器就丢了。中间层答案：把筛选条件同步到 URL query，刷新后读取 URL 恢复。这个方案更稳，还能支持分享链接直达目标页。高级答案会补充：列表数据要不要缓存？如果用户返回是为了看某个字段，直接用缓存数据渲染，不重新请求；但如果数据有变化，可能还是要拉新数据。这里涉及缓存与数据新鲜度的权衡，候选人能主动说出来，说明真有业务思辨能力。
参考思路：
- 筛选条件和页码优先写入 URL 的 query 参数，数据结构尽量扁平；
- 如果需要跨页面共享列表状态，用 keep-alive 或组件缓存；
- 滚动位置恢复要考虑图片懒加载导致的滚动高度变化，最好等到列表数据渲染完、图片尺寸占位生效后再恢复；
- 数据刷新策略需要产品参与确认，不要自己拍板。
这道题暴露的短板：只会用组件内 state 包打天下，不考虑 URL 作为低成本持久化方案；也不会主动权衡“缓存数据的好处”和“脏数据的风险”。实际上后面这个权衡点，在真正做中后台系统时，比任何 API 都重要。
2.10 第 10 题：接手一个 6 年的 Vue2 老项目，你要不要推倒重写
题目：公司有一个运行了 6 年的 Vue2 后台管理系统，技术栈老旧，存在大量业务逻辑，但仍在稳定运营。老板希望“升级到 Vue3 提升可维护性”，你作为新来的前端负责人，怎么推进？
考察点：技术债务治理、渐进式重构策略、风险评估、版本升级路径、团队协作安排。
这道题基本是“送命题”：很多人会不假思索地说“直接迁移到 Vue3”，完全没意识到 6 年老项目的复杂度。正确思路是先量化风险：项目有多少个页面、多少个组件、依赖了哪些 Vue2 专属生态库（比如 vuex、vue-router 3、element-ui），这些库在 Vue3 下是否有替代品，业务团队能否支撑一次性迁移。
参考思路：不建议一步到位重写，而应该走渐进式方案。Vue3 提供了兼容构建，可以在 Vue3 项目里继续运行部分 Vue2 组件，也就是说迁移可以按模块一批批来。先把核心依赖列出来，评估风险等级最高的模块，用自动化测试锁定关键业务路径，再开始改造。对外，要给老板一个时间表和风险清单，不要只写“提升开发体验”，要量化“减少多少构建时间、减少多少线上报错”。
这道题暴露的短板：候选人如果只说“用 vite 重写”，说明他根本没意识到老项目承载的业务连续性风险。做过真实重构的人，一定会提到“回归测试保障”、“依赖锁定”、“灰度上线”、“回滚预案”这些关键词。
3. 面试现场最常见的三个“答非所问”瞬间
3.1 背了响应式原理，却看不懂一个小页面为什么不更新
有很多候选人，讲 Vue2 的 Object.defineProperty 和 Vue3 的 Proxy 差异时侃侃而谈，但第 3 题这种偏“应用原理”的题反而答不出来。我印象很深的一次，候选人认为是 Vue 检测不到对象新增属性，直接就往“$set”方向上引了——可题目里明明是在改已有的属性。
这类人不是没有基础，而是把知识背成了“接口文档”，没有形成问题驱动的思维方式。后来我调整了应对方式：不提醒他，让他先说排查步骤。如果他能说出“我先看这个对象是不是响应式的”，说明他脑子里有排查模型，只是慢热。
3.2 一让写代码就露馅，背诵型选手和实战型选手的分水岭
第 7 题并发调度器，很多人能讲清楚大文件上传里 Worker、切片、断点续传的理论，但一提笔写代码，就发现连Promise.race都不熟练。更常见的错误是：
for (let i = 0; i < tasks.length; i++) { if (executing.size >= limit) { await Promise.race(executing); } executing.add(task()); }这里面有两层问题：promise 还没执行就被放进了 executing；并且在并发池已经满员时没有等待任何结果就开始下一轮循环。真正的并发调度，第一步是拿到任务就启动，不要让任务因为入池时机不对而变成串行。这个错误在真实项目里很常见，尤其是一次性上传几百个文件时，你会发现浏览器卡到无法点击——所以这道题已经不只是面试题，而是工程灾难的预防训练。
3.3 性能优化题，答成了“背优化手段清单”
第 5 题和第 6 题，很多候选人确实知道 CDN、压缩、路由懒加载这些词，但一追问“你怎么确认优化后首屏真的变快了”，就支支吾吾。正确的数据验证方式包括：用 Lighthouse 对比优化前后的 Performance 得分、记录 DOMContentLoaded 和 load 时间、在 Performance 面板看长任务数量、用浏览器性能监控采集 FCP/LCP 指标。
没有真实项目数据支撑的优化方案，面试官听得出来是背的。我会让候选人说一个他遇到过最离谱的性能 bug，能讲得出排查细节的人，才是真的做过。
4. 这套题怎么用，才能做到既“考能力”又不“为难人”
4.1 作为面试官：每道题准备两个追问层级
如果候选人在第一层就能答好，说明基础扎实，直接进下一个主题；如果答得一般，可以用追问把候选人的思维方式带出来。比如第 1 题做完后，追问“把 await Promise.resolve() 改成 await new Promise(resolve => setTimeout(resolve, 0)) 会怎样”；第 6 题说完后，追问“如果 TTFB 高是因为后端接口慢，前端能做什么兜底动作”。这样既考察深度，也给候选人发挥空间，不会让面试变成“审判”。
4.2 作为候选人：用这套题做一次“能力雷达扫描”
我建议你按这个顺序自测：先不看参考思路，把每一题的回答写下来，或者跟朋友口头讲一遍。每题能讲到什么程度打个分：完全说不清 (1分)、能说出关键词但逻辑混乱 (2分)、能完整推演并落到方案 (3分)。
10 题做完，把得分拉成雷达图，很容易看到自己的短板分布：
- 如果集中在 2.1、2.2，那是 JavaScript 底层理解不牢，需要补事件循环和渲染管线的实战场景；
- 如果集中在 2.3、2.4，那是框架应用停留在 API 调用，没有深入响应式机制和状态设计；
- 如果集中在 2.5、2.6、2.7，那是工程化和性能实践经验不足，建议去真实项目里做一次构建优化和上传模块；
- 如果集中在 2.8、2.9、2.10，那是系统设计和问题排查经验还要沉淀，多参与线上事故复盘和技术重构。
4.3 自测之后的三条复习建议
第一，不要背题。这套题目的核心是“现场推演”，你把答案背下来了，换个场景依然不会。第二，拿真实项目验证，比如第 7 题，你可以真的实现一个大文件上传 demo，用 Worker 算 hash、并发调度、失败重试都走一遍，踩一遍坑比刷 50 道题有用。第三，找人模拟面试，自己写答案很容易自我感觉良好，找水平的同行互相提问，追问环节最能暴露知识盲区。
5. 面试官视角的复盘心得
我把这套题用在多次面试里，最大的感受是：真正强的人，不需要把每道题都答到满分。我见过有人第 1 题事件循环答错了 B 和 D 的顺序，但第 4、9、10 题表现极好，会反问业务场景，会给出取舍方案。这种候选人到最后常常拿到 offer——因为事件循环可以补，但架构判断力和业务思维是长期项目经验沉淀出来的。
反过来，也有人前三题背得完美，但一到开放性设计题就“场面话连篇”。这种候选人像“题目型选手”，遇到真实项目复杂度就失去抓手。而我出这套题的目的，正是要在 1 个小时里把这两类人分清楚。
如果你想把这套题用在自己的面试里，我建议搭配一个实际的编程环节：现场给一个小需求，比如“实现一个带并发限制的请求函数”“改造一段 watchEffect 不触发的代码”，让候选人打开编辑器写。因为所有口头答案都可以包装，代码不会骗人。这也是我在面试了上百人之后，最想分享给同行的一句话——面试题本身没有意义，有意义的是你从候选人的回答里，看到了他真实工作状态的剪影。
