年前一个月搞定Web前端面试：从刷题到模拟的完整复盘

写在前面：我不是什么大厂面试官，也不是培训机构的讲师。我只是一个年前被年终复盘和跳槽念头反复折磨的前端开发，在别人抢春运票、晒年终奖的那几周里，把每天下班后的三小时全砸在了Web前端面试题上。这篇文章不打算给你列一个“背诵全文”的题库清单，而是想完整复盘那一个月里我是怎么刷题、怎么整理错题、怎么把自己从“看到八股文就头疼”的状态调整到“进面试间能稳住不慌”的状态。如果你也在准备前端面试，或者打算年后换工作，这篇东西应该能帮你少走不少弯路——至少能让你知道，年前这段时间到底该干什么、不该干什么。

1. 为什么非要在年前这段时间把自己按在题桌前

1.1 年前的时间窗口被严重低估了

很多人觉得年前找工作没戏，公司都在收尾、HC（Headcount）冻结，所以刷题也是三天打鱼两天晒网。我恰恰相反——年前恰恰是刷Web前端面试题性价比最高的一段空窗期。

原因有三。第一，你所在的公司业务节奏普遍放缓，白天摸鱼的空间变大，晚上也没有那么多临时需求打断你；第二，年后“金三银四”窗口一开，面试会扎堆，如果等到二月底才开始刷题，你会发现既要做简历、又要投递、还要应付一面二面，根本没办法沉下心来搞基础；第三，我自己最大的感受是，年前刷题有一个“天然截止日期”——春节假期前必须完成一轮系统复习，这个deadline会让你的执行力和平时完全不同。

所以我给自己定的策略很简单：年前一个月主攻基础题和手写题，春节假期把框架源码和项目复盘串一遍，年后回来直接进入投递和模拟面试节奏。事实证明，这个排序是对的。

1.2 我的刷题计划表和每天的时间切片

整个计划分三个周期，每个周期大约十天：

• 第一周期（1-10天）：地毯式过前端基础题，包括HTML/CSS/JavaScript/浏览器/网络，目标是“看到题能说出个一二三”。
• 第二周期（11-20天）：主攻框架题（Vue3、React）和手写题，这两块是面试的硬骨头，必须动手敲。
• 第三周期（21-30天）：项目复盘、模拟面试、针对薄弱点定向扫题。

每天的时间切片我是这样安排的：

• 早上通勤半小时：看昨天的错题记录，不学新知识，纯粹温习。
• 中午午休20分钟：刷3-5道高频选择题或概念题，保持题感。
• 晚上20:30-23:30：三小时整块时间，前一小时学新知识点，后两小时做专项练习和手写题。
• 周末挑一个上午：做一套完整的模拟题，严格按面试题量和时间限制来。

这里有个细节：晚上的三小时里我会把手机放到另一个房间。不是玄学，是实测下来这样效率能提高一倍。刷题的状态最怕被碎片消息打断，一次打断至少要五分钟才能重新进入深度思考。

2. 动手刷题前，先给知识体系做一次“体检”

2.1 面试考点地图：按出题频率划分的五个梯队

刷Web前端面试题最忌讳的就是拿到题就刷，从头刷到尾，刷到后面忘了前面。我在第一周先干了一件看起来没什么用的事：把市面上常见的面试题做了一次分类，按照出题频率排成五个梯队。

做完这个地图之后，我心里就踏实了很多。因为你会发现面试题虽然多，但高频考点是有限的。你不一定每一块都深挖到源码，但第一梯队、第二梯队必须做到“闭眼能讲”。

2.2 自测与补课：哪些是背了就能答的，哪些必须动手练

分类完成后我做了30道自测题，就是随便从各梯队抽出来的真题，比如：

• “call、apply、bind 有什么区别？手写一个 bind”
• “Vue3 的响应式为什么用 Proxy 而不是 Object.defineProperty？”
• “Flex 布局中 flex: 1 表示什么？底层怎么计算？”
• “从输入 URL 到页面展示，中间发生了什么？”

做完这30道题，我给自己划分成了三类：

1. 脱口而出型：看到题不用想就能答，这类基本不用再投入大量时间，只需定期复习巩固。
2. 有印象但说不透型：知道大概意思，但一深问就卡壳，比如能说出 BFC（Block Formatting Context），但说不清它到底解决了什么问题、怎么触发。这部分是主要补课对象。
3. 完全没头绪型：比如手写 Promise.zip、实现一个 LRU 缓存、Vue3 的 render 函数源码。这类必须老老实实从原理学起。

这种“体检”式自测比直接刷题高效得多。它帮你把有限时间全花在刀刃上，而不是每天感觉刷了很多题，真正面试时却发现到处是洞。

3. 三块最啃人的硬骨头：原理、手写、框架源码

3.1 JavaScript原理题：背结论不如推演一遍

JavaScript基础题是前端面试题的基本盘，也是我年前刷题时花时间最多的一块。一开始我也想过直接背题，但很快发现行不通——面试官现在特别会追问。比如你背了“闭包就是函数内部访问外部变量的能力”，他会追问“那闭包会造成内存泄漏吗？怎么避免？”，你背了“事件循环有微任务和宏任务”，他会追问“Promise resolve 之后注册的 then 在哪个阶段执行”。

正确的做法不是背结论，而是推演。拿事件循环来说，不要只背“微任务先于宏任务”，而是要能完整走一遍这道题：

javascript复制console.log('1');

setTimeout(() => {
  console.log('2');
}, 0);

Promise.resolve().then(() => {
  console.log('3');
});

console.log('4');

输出顺序是 1、4、3、2。如果你只背结论，可能知道微任务优先于宏任务，但如果题目换成 async/await，换成嵌套的 Promise.then，甚至换成 requestAnimationFrame，你还需要知道它们分别排在哪个阶段。所以我会把一道原理题拆成多个变体，用代码实际跑一遍，看输出结果和预期是否一致。这种“自己给自己出变体题”的方式，比刷十道不同的题更让我印象深刻。

另外，原型链和 this 指向这两块也是高频中的高频。我的体会是不要死记硬背 call/apply/bind 的区别，要画图。在纸上画出 Function.prototype、Object.prototype、arr.__proto__ 这条链，很多题自然就通了。

3.2 手写题清单和防抖函数的完整拆解

手写题是Web前端面试题里最需要“动手”的部分，也是我从“看答案觉得自己会”到“合上答案发现自己写不出来”落差最大的一块。我整理了一份手写题高频清单，这里也分享给大家参考：

• 深拷贝（考虑循环引用、Symbol、日期、正则）
• 防抖（debounce）和节流（throttle）
• Promise.all、Promise.race、Promise.allSettled
• call、apply、bind 的实现
• new 的实现
• instanceof 的实现
• 数组扁平化、数组去重
• 函数柯里化
• 发布订阅模式（EventEmitter）
• LRU 缓存淘汰算法

我拿防抖函数举例，说一下我踩过的坑。第一版我写得很快：

javascript复制function debounce(fn, delay) {
  let timer = null;
  return function () {
    clearTimeout(timer);
    timer = setTimeout(fn, delay);
  };
}

这版看起来没什么问题，但面试官一定会问：“如果回调函数里需要用到 this 和参数呢？”我第一反应是“用什么 arguments”，但忽略了 this 的透传。正确的写法应该是：

javascript复制function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    const context = this;
    clearTimeout(timer);
    timer = setTimeout(() => {
      fn.apply(context, args);
    }, delay);
  };
}

再加一层：需要立即执行版本，或者需要取消防抖。这东西如果不亲自写一遍，光靠看答案，面试时一定会被现场写代码打回原形。所以我后来要求自己：所有手写题必须不参考任何资料，在编辑器里从头到尾敲出来，并且能讲清楚每一行为什么这么写。

3.3 框架题：Vue3 和 React 到底在问什么

框架题是另一块硬骨头，而且这两年明显在往源码方向深挖。

Vue3 方向，我刷到最频繁的几道题是：

• Vue3 的响应式原理为什么用 Proxy 替代 Object.defineProperty？
• ref 和 reactive 的区别是什么？
• computed 的实现原理？
• Vue3 的 diff 算法相比 Vue2 做了什么优化？
• nextTick 的原理？

这类题的答法不是我背一个标准答案就完事，而是要能结合源码解释。比如 Proxy 替代 defineProperty 的原因，至少要说清三点：defineProperty 只能监听属性，对新增属性、删除属性无能为力；defineProperty 需要递归遍历对象，性能差；Proxy 可以代理整个对象，天然支持新增/删除属性，并且拦截层面更丰富。然后可以补充一句“Vue3 还用了 WeakMap 做依赖收集的缓存，避免重复代理”，这样面试官会知道你真的看过源码。

React 方向，高频题有：

• Hooks 相比 class 组件有什么优势？
• useEffect 的依赖数组机制，闭包陷阱怎么产生的？
• React 的 fiber 架构解决了什么问题？
• key 的作用是什么？为什么用 index 作为 key 会带来 bug？

React 的闭包陷阱这道题特别容易翻车。很多人知道 useEffect 里拿不到最新 state，但说不清为什么。我在刷题总结时是这么理解的：每次渲染，函数组件都会重新执行一次，useEffect 的回调函数捕获的是本次渲染闭包里的 state，所以如果你不把它加进依赖数组，回调里拿到的永远是“上一次渲染时的值”。这个理解一旦建立起来，很多相关变体题都能迎刃而解。

框架题我建议不要追求“背全”，而是挑一个你真正用过的框架深挖下去。面试官更看重“你真正用过并思考过”，而不是“你会背八股文”。

4. 一道题反复错之后，我总结出来的复盘方法

4.1 错题本的分层记录方式

刷题刷到第三周，我发现一个问题：有些题我明明刷了三遍，过几天再做还是错。一开始我以为是记忆问题，后来发现是因为我的错题记录方式太敷衍了——只是在题旁边打个叉，或者把答案抄一遍，根本没有分析“为什么错”。

后来我改成了一种分层记录法，每道错题按三个维度记录：

1. 错在哪一步：是概念完全没理解，还是理解了一部分但漏了细节，还是表达时卡壳了？
2. 正确答案里的关键点是什么：比如一道“实现深拷贝”的题，关键点是循环引用和特殊类型处理，而不是“把对象遍历一遍”。
3. 如果重新答，我会怎么组织语言：这一步很关键，因为面试不是做题，是“说题”。

举一个真实的例子。我连续错了三次的一道题是“HTTP 缓存哪些字段分别由谁控制”。第一次错在把 Cache-Control 和 Expires 弄混；第二次能分清字段了，但说不清协商缓存的流程；第三次我已经能把流程说清楚，但漏了 ETag 和 Last-Modified 的优先级关系。每一层错的都不一样，只有记下来才能精准补漏。

4.2 以题带面的关联扩展，而不是单点记忆

错题分层之后，我还用了一个特别重要的方法：以题带面。也就是不孤立地刷一道题，而是把每题当成一个节点，向外扩展。

比如遇到 “手写 Promise.all” 这道题，我的扩展步骤是：

1. 把 Promise.all、Promise.race、Promise.allSettled 全部手写一遍；
2. 想一想它们分别在什么场景下使用：all 是并发接口请求，race 是超时处理，allSettled 是只要结果不关心成败；
3. 再往前延伸，Promise.all 有什么缺点？如果一个请求挂了，整个就挂了，怎么优化？——可以用 allSettled，或者用并发控制分批请求；
4. 最后再追问：并发控制怎么实现？这就引出了一个高频手写题，实现一个 asyncPool 或者“限制最大并发数”的函数。

这样一道题就能串起五道题的知识。刷题效率高的人，基本都是用这种“一棵树刷成一整片森林”的方式在学，而不是单纯堆积题目数量。

4.3 间隔重复自己的“讲题录音”

这个方法是我在年前刷题后期自己摸索出来的，效果意外地好。

我的做法是：每天选两到三道当天最难、最有价值的题，用自己的话把答案讲一遍，用手机录音，每道题控制在三分钟左右。然后隔一天、隔三天、隔七天分别回听一次。这套节奏借鉴的就是艾宾浩斯遗忘曲线的原理。

回听的时候，你会发现自己讲着讲着就卡壳了，或者某句话逻辑不对，或者专业术语用错了。这些都是记忆里隐藏的缺口，平时刷题时根本不会暴露——因为你刷题时是“看懂”，而讲题时是“输出”，输出才能暴露短板。

录音还有一个额外好处：训练表达节奏。Web前端面试题的口述环节，和手写环节同样重要。很多人代码写得出，一说就前言不搭后语。录过几次音之后，你会不自觉地调整语速、控制停顿，这个能力在真正的面试里非常加分。

5. 刷题之外：项目复盘和简历术语的同步打磨

5.1 把项目浓缩成3分钟版本

刷题刷到第三周，我的危机感反而不是来自算法题和框架题，而是来自“项目经历怎么讲”。网上很多前端面试题的答案教你怎么答八股文，但项目经历是要靠你自己组织的。

我当时的项目复盘方法是STAR法则的变体：

• 背景：一句话说清楚这个项目是给谁用的、解决什么问题。
• 难点：挑出整个项目里最有技术含量的两个点，比如大规模数据渲染卡顿、权限控制混乱、首屏加载慢。
• 方案：针对难点你具体做了什么，用了什么技术，为什么这么选。
• 结果：用了什么可量化的指标来验证效果，比如首屏时间从3秒降到1.5秒。

比如我之前写过一个后台管理系统，第一次准备面试时我是这么说的：“我做了一个后台管理系统，里面做了用户登录和权限管理。”这种描述等于没描述，面试官没有任何可以追问的抓手。

复盘之后我改成这样：“这个系统的核心痛点是权限模型混乱，不同角色能看到哪些菜单、按钮完全没有统一控制。我用 Vue3 配合路由守卫和动态路由表实现了基于 RBAC 的权限控制，前端通过接口动态获取用户角色，再根据角色生成菜单和可访问路由；按钮级别用自定义指令控制显隐。”然后我还补充了一个细节：“由于后端返回的菜单树和前端静态路由存在联动关系，我抽了一个通用的路由映射工具函数，避免每次都要在路由表里手工维护权限。”

这么一说，面试官明显更愿意继续往下问，而且问的都是你有准备的问题。

5.2 性能优化、鉴权、脚手架这些高频追问点

项目复盘之外，我整理了三个面试官几乎必问的高频项目追问点：性能优化、鉴权方案、工程化配置。

性能优化这块，我给自己准备了一个“从请求到渲染”的口径：前端优化无非三个层面，减少请求数量、减小请求体积、优化渲染过程。减少请求可以聊懒加载、雪碧图、HTTP缓存；减小体积可以聊代码分割、Tree Shaking、Gzip；优化渲染可以聊虚拟列表、骨架屏、避免不必要的重排重绘。关键是要结合自己的项目说，哪怕只是做了其中两件事，也比泛泛而谈“我用过懒加载”更有说服力。

鉴权方案这块，要能讲清 token 存在哪里、怎么续期、请求拦截器做了什么、401 了怎么处理。我自己踩过 token 存 localStorage 被 XSS 攻击的问题，所以复盘时把“为什么后来改用 httpOnly cookie + 刷新 token 机制”也准备了进去。

脚手架配置这块，很多前端平时只负责 npm run dev，对 Webpack 配置一问三不知。我花了一天时间把项目里的 webpack 配置重读了一遍，重点搞清楚 entry 和 output、loader 和 plugin 的区别、splitChunks 是怎么把公共依赖拆出来的。面试官问到这个话题时，我至少能接上话，而不是一句“公司有专门的人配置工程化”。

6. 春节前的最后冲刺：模拟面试与状态校准

6.1 我在最后七天做的四件事

最后七天，我没有再刷任何新题。这个阶段最关键的不是“学更多”，而是“稳住状态”。我给自己定了四件事：

一是限时手写题。每天随机抽5道手写题，每道15分钟，写在白纸上，不自动补全、不加高亮，模拟面试现场写代码的环境。这期间我发现有一些题我虽然会写，但一离开 IDE 的提示就写得磕磕绊绊，这种问题必须提前暴露。

二是参加模拟面试。我找了一位也在准备跳槽的朋友，互相面试，每人当面试官一小时。重点不是考倒对方，而是让对方问出“你没准备过的问题”，锻炼临场应变。

三是回归错题本。把所有录音重新听一遍，把微信收藏里吃灰的题全部清理掉。我用了一个很简单的筛选标准：如果现在我看着题目能在30秒内说出完整答题思路，就放过去；否则，立刻打开笔记重新过一遍。

四是调整作息。最后三天我强制自己晚上12点前睡，早上8点起，不再熬夜刷题。因为面试状态和刷题状态不一样，面试需要的是清醒的头脑和流利的表达，睡眠不足最大的影响是脑子转得慢、说话打结。

6.2 面试间里那些刷题给不了的临场判断

真正走进面试间之后，我发现刷题带来的不只是知识储备，更重要的是一种“有底气”的心理状态。那种感觉很难说清，但面对一道你没见过的Web前端面试题时，你不会慌，而是会下意识地拆题：

• 这道题考的是哪个知识板块？
• 我能不能从自己熟悉的概念往这道题上靠？
• 我不会的部分是核心还是边缘？如果用排除法说出去会不会扣分？

有一次面试官问我一个关于渲染层级的刁钻问题，我确实没准备过。但我没有说“不会”就结束，而是说：“这个点我没有深入研究过，不过我理解它跟 CSS 的层叠上下文有关，我讲一下我对层叠上下文的理解，您看是不是这个方向。”面试官后来告诉我，这种“遇到不会的题敢接球”的态度，比会背十道题更有价值。

这其实是刷题过程中潜移默化练出来的临场判断力——你见过了太多变体题和追问，就会明白面试官的问题几乎都是从一个基础点扩散出来的，只要你能定位到“这个题在考哪个基础点”，就基本稳住了。

如果你想复刻我年前这段刷题状态，我的核心建议只有一条：不要用“我今天刷了多少题”来麻痹自己，要用“我能不能把一道题完整地讲给另一个人听”来检验自己。前端面试题背不完，但原理和思维方法是有限的。把自己当成一台“知识处理器”，而不是“题库复印机”，这套状态到什么时候都不过时。