第四范式前端笔试复盘：从JS到算法，原理型选手的筛选

1. 这套笔试到底在考什么：题型分布与考察逻辑

2020年秋招那阵子，我收到第四范式的笔试链接时，第一反应是：一家做AI平台的公司，前端笔试会不会剑走偏锋，比如考一堆机器学习概念或者算法推导？真点开试卷之后发现，它比我想象中"正"得多，整体偏向大厂通用前端能力，但有几道题的出题角度确实带着明显的工程化倾向，和纯业务型公司的笔试题有明显差异。

整套题大致可以分成五个模块：JS语言基础、异步与事件循环、CSS与浏览器原理、框架与工程化、算法与数据结构。考试时长大概90分钟，题目总量不算夸张，但真正拉分的地方在于"看着都会，写起来全错"的细节题比较多，而且算法题占比不低，需要你在有限时间内直接手写完整解法。

从考察逻辑上看，这套笔试题的核心意图已经不是"筛掉不会写代码的人"，而是"在会写代码的人里筛出真正理解前端运行机制的人"。比如同样的一个闭包题，普通公司可能考到"输出什么"，第四范式的题目会多追问一步"如果想达到预期输出，应该怎么改"，这就把记忆型选手和原理型选手直接分开了。

另外，因为第四范式本身就是做AI平台和可视化产品的，所以CSS布局、Canvas渲染、大数据量列表优化这类题目出现频率比一般电商或内容类公司更高。如果你只是刷过常规前端面试题库，没接触过数据密集型应用场景，有几道题可能会觉得别扭。

下面我把每一类题型的考查重点、题目还原、解题思路和失分点逐个拆开讲。我会尽量把当时试卷里的出题角度还原出来，再补充一些同类变体，给准备这类笔试的同学一个完整的对照参考。

2. JS基础题的"温柔一刀"：原型链、闭包与this指向

2.1 原型链题：画图谁都会，写代码才见真章

这套笔试题里JS基础部分的第一道题，长这样：

function Parent() { this.name = 'parent'; } Parent.prototype.getName = function() { return this.name; }; function Child() { this.name = 'child'; } Child.prototype = new Parent(); const child = new Child(); console.log(child.getName()); console.log(child instanceof Parent); console.log(child.hasOwnProperty('name'));

考察点非常集中：原型链继承的方式、instanceof的判断逻辑、hasOwnProperty和原型链属性的区别。这道题输出结果是child、true、true，大部分基础扎实的同学都能答对，但它真正的杀手锏是后面一道追问：

Child.prototype.constructor === Child // 输出？

答案是false。因为Child.prototype = new Parent()这行直接把Child.prototype指向了Parent实例，而这个实例的constructor是Parent，所以Child.prototype.constructor指向的是Parent。这个问题在当时很多同学那儿都是丢分点，因为平时写Child.prototype = new Parent()已经是惯例写法了，很少有人意识到还需要手动补一行Child.prototype.constructor = Child来修正。

这类题表面考的是原型链，实际上考的是"你是否真的理解JS继承的本质"。原型链继承的本质是让子类的原型指向父类实例，子类实例在查找属性时会沿着__proto__链一路向上，直到找到为止。画原型链图谁都会，但落到代码里，constructor丢失这种细节才是笔试想挖的坑。

2.2 闭包与作用域：不是背概念，而是推理执行过程

闭包题是必考，这套题里考得挺典型：

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

这是每个前端人见过无数次的经典题，输出是5个5。如果你以为考点只是"var没有块级作用域"，那就低估出题人了。这道题后面紧跟的追问是：请在不使用let的前提下，用闭包方式修复这段代码，并解释为什么你的修复方案能生效。

参考答案是：

for (var i = 0; i < 5; i++) { (function(j) { setTimeout(function() { console.log(j); }, 100); })(i); }

关键是解释：每次循环时，立即执行函数创建了一个新的函数作用域，参数j接收了当前循环的i值并保存在自己的作用域中。当100毫秒后回调函数执行时，它通过闭包引用的是那个已经被固定下来的j，而不是循环结束后已经变成5的i。

这类题在笔试中的真正作用，是区分"背答案的人"和"理解闭包的人"。因为单纯背答案的人能写对修复代码，但解释不清楚为什么IIFE能隔离变量。闭包的定义并不复杂——函数能够记住并访问它创建时所处的作用域，哪怕这个函数在外层作用域已经执行结束后才被调用——但要把这个定义用在实际代码里讲清楚，需要的是对执行上下文和作用域链的完整理解。

2.3 this指向：谁调用，指向谁，但也要小心箭头函数

this指向题也是高频考点，这套笔试题里出了一道混合箭头函数和普通函数的题目：

const obj = { name: 'obj', getName: function() { return this.name; }, getNameArrow: () => { return this.name; } }; console.log(obj.getName()); console.log(obj.getNameArrow());

obj.getName()输出obj，没问题。obj.getNameArrow()输出什么？答案取决于运行环境。在浏览器全局环境下，箭头函数的this在定义时就决定了，它继承的是外层作用域的this，也就是全局对象，所以this.name是undefined。

这类题目考查的是对箭头函数本质的理解：箭头函数没有自己的this，它的this是在词法层面绑定的，等价于它定义位置的外层普通函数的this。这个特性在普通面试里可能一句话带过，但在笔试里，它要和"谁调用指向谁"的普通函数规则放在一起考，如果你只是机械记忆"箭头函数不能当构造函数"这类结论，很容易在这种对比题上判断失误。

2.4 手写实现：深拷贝、防抖节流、函数柯里化

除了选择题和输出题，这套笔试题的基础部分还有一道手写题，要求实现一个深拷贝函数，并且要能处理循环引用。这个要求比"深拷贝一个普通对象"高了不少，因为一旦对象内部出现循环引用，简单的递归拷贝会直接栈溢出。

标准解法是借助WeakMap来记录已经拷贝过的对象：

function deepClone(target, map = new WeakMap()) { if (typeof target !== 'object' || target === null) { return target; } if (map.has(target)) { return map.get(target); } const clone = Array.isArray(target) ? [] : {}; map.set(target, clone); for (const key in target) { if (target.hasOwnProperty(key)) { clone[key] = deepClone(target[key], map); } } return clone; }

这里选择WeakMap而不是Map是有讲究的：WeakMap的键是弱引用，不会阻止垃圾回收机制回收原对象。在深拷贝这种临时场景下，用WeakMap避免内存泄漏风险，比Map更合适。而且WeakMap的键只能是对象类型，正好符合这里的使用场景。

这道题在笔试中的区分度其实不在"会不会写深拷贝"，而在"有没有考虑循环引用"。能写出基础深拷贝的同学很多，但主动处理循环引用的可能不到三成。这也反映了笔试的残酷性：不是看你会什么，而是看你能考虑到什么边界情况。

2.5 基础题备考建议：别只看结论，多追问自己一个"为什么"

从这套基础题来看，第四范式考察的基础能力并不是静态的知识点记忆，而是动态的执行过程推演。如果你只在面试前背一遍"闭包是函数和其词法作用域的组合"，那是远远不够的。你需要能在纸上一步步推演代码的执行过程，知道每一步创建了什么作用域、引用了什么变量、this指向哪里、输出会在什么时机产生。

我的建议是：刷这类题时不要只看标准答案，试着自己把执行过程画成表格，标注每一行代码执行时作用域链的变化、变量状态的变化。这个过程本身就是一次深度复习，比刷10道新题更有效。

3. 异步与事件循环：那些你以为稳拿分的题目

3.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 setTimeout

最容易出错的地方在async1 end和promise2的先后关系。如果你对await的理解是"await后面的代码会等待Promise resolve后再继续执行"，那你可能会以为async1 end会输出在promise2之后，但实际结果是async1 end先于promise2。

原因在于，await async2()这一行的语义可以拆解为：先执行async2()，得到它的返回值（一个Promise），然后立即把await后面的代码作为微任务排队。而new Promise().then(...)也是把回调作为微任务排队。关键在于排队顺序：await后面的代码先进入了微任务队列，之后promise1的.then回调才进入队列，所以按先进先出的原则，async1 end先输出。

这道题还有一层更深的考点：await后面的代码，实际是在当前async函数的Promise状态变为resolved后，才被放入微任务队列的，而async2内部没有await，它的console.log是同步执行的。这就是为什么async1 start和async2会连续输出，中间没有任何微任务切换。

3.2 宏任务和微任务的底层逻辑：不是背顺序，而是理解队列机制

很多人遇到这类执行顺序题，靠的是背诵一张"宏任务优先级、微任务优先级"表。但笔试的出题人显然知道大家会背，所以会在题目里设计一些不在表上的变体来增加难度。比如常见的优先级总结是"process.nextTick > Promise > setTimeout"，但如果你只背这个顺序，遇到上面那道题还是会栽在async1 end和promise2的先后上。

根本原因在于，宏任务和微任务的分类只是表象，真正决定执行顺序的是"队列"和"入队时机"。每次事件循环都会先处理一个宏任务，然后清空当前的微任务队列，清空过程中新产生的微任务也会继续执行。所以，不管setTimeout设置的是0延时还是10延时，它都只能在当前宏任务的所有微任务执行完毕后才有机会进入执行。而两个微任务之间的先后顺序，取决于它们进入微任务队列的时间，而不是书写位置。

3.3 手写Promise.all：实现不算难，难在边界条件的完备性

异步模块的最后一道题是手写Promise.all，这算是笔试中的"诚意"题目了，因为它不只考API，还考你能否实现一个足够健壮的Promise方法。我当时的实现思路是：

Promise.myAll = function(promises) { return new Promise((resolve, reject) => { if (!Array.isArray(promises)) { reject(new TypeError('promises must be an array')); return; } const results = []; let count = 0; const len = promises.length; if (len === 0) { resolve(results); return; } promises.forEach((promise, index) => { Promise.resolve(promise).then( (value) => { results[index] = value; count++; if (count === len) { resolve(results); } }, (reason) => { reject(reason); } ); }); }); };

这道题的完整解答需要覆盖几个关键点：入参校验、空数组处理、结果顺序与原数组一致、非Promise值兼容、以及任何一个Promise reject后立即reject。能写对Promise.all本身不难，难的是在笔试时间压力下还能注意到空数组resolve、结果按下标存放这些细节。

3.4 并发控制题的加分点：如何设计一个带限流的异步队列

第四范式的笔试题里还有一道偏进阶的异步题：实现一个并发池，限制同时最多并发3个任务，任务完成后自动补充新任务。这道题当时我写的时候思路是维护一个执行队列，用一个running计数器控制并发数，每次启动任务时检查当前并发数是否达到上限。

核心代码如下：

function createConcurrencyPool(tasks, limit = 3) { const results = []; let running = 0; let index = 0; return new Promise((resolve, reject) => { function run() { if (index >= tasks.length && running === 0) { resolve(results); return; } while (running < limit && index < tasks.length) { const current = index++; running++; Promise.resolve() .then(() => tasks[current]()) .then((result) => { results[current] = result; running--; run(); }) .catch((err) => { reject(err); }); } } run(); }); }

这道题的实际价值在于，它把"事件循环""回调""并发控制"这些概念串在了一起。很多同学能写出来，但解释不清为什么在.then里要继续调用run()。其实run()的地位相当于"任务完成后的调度器"，它在每次任务结束后判断是否还有剩余任务，以及当前是否还能再启动新任务。把这个机制讲清楚，比代码本身更能体现你的工程思维。

这类并发池在实际项目中的应用场景很多，比如批量上传文件时控制同时上传数量、爬虫控制请求并发度、前端数据面板同时拉取多个接口但不想压垮服务端。面试官问这道题，往往是在考察你有没有真正处理过这种"资源有限但任务很多"的工程问题，而不仅仅是背Promise API。

4. CSS与浏览器原理：数据密集型产品的前端功底试金石

4.1 盒模型与BFC：基础概念，但追问起来能问哭人

CSS部分的第一道题是盒模型的对比：标准盒模型和IE盒模型的区别，以及如何用CSS切换。box-sizing: content-box和box-sizing: border-box的对比，学过CSS的人都能答。但紧接着的第二问就有点刁钻了：在什么场景下你必须使用border-box，否则布局会出现问题？

这个问题的答案有很多种，我当时写的是"栅格布局和百分比宽度场景"。如果你在一个容器里设定两个子元素各占50%宽度，同时给它们加上padding或border，在content-box下，两个子元素的实际宽度会超过父容器宽度的100%，导致换行。改成border-box后，50%是指包含padding和border的总宽度，两个子元素才能正好排在一行。

BFC这道题考点更经典：问如何触发BFC，以及BFC能解决什么问题。触发方式包括浮动、绝对定位、display: inline-block、overflow非visible、flex容器的直接子元素等。BFC能解决的核心问题包括：清除内部浮动、防止外边距合并、阻止元素被浮动元素覆盖。这些背都能背下来，但笔试真正想考的是——给你一段已经出现布局Bug的代码，你能不能反推出问题根源是BFC没有被正确建立。

4.2 Flex布局：从"会写"到"能算"

Flex布局题在这套卷子里有一个很有意思的考查方式：给你一个flex容器，它的flex-wrap: wrap，每一个子项的flex: 0 0 30%，问一行能放下几个子项。很多人答3个，但实际要看容器宽度和子项之间是否有margin或gap。如果子项设置了margin: 1%，那么实际占用的宽度是30%加2%的margin，一行只能放下2个。

这类题考的其实是你对Flex布局主尺寸计算规则的理解：在flex-basis明确、flex-grow和flex-shrink都为0的情况下，子项占用的空间就等于它的基础尺寸加上margin、padding、border。一旦总宽度超过容器宽度，就会触发换行。这种"需要动笔算"的布局题，比问"justify-content有哪些取值"高了好几个维度。

这背后反映的是第四范式这类做数据可视化平台的公司对前端的要求：布局不是"差不多能看就行"，而是要在不同屏幕尺寸下精确还原设计稿，在表格、图表、复杂仪表盘里处理大量密集的子元素排列。如果你的CSS功底停留在"会用flex就万事大吉"的程度，到真实项目的响应式布局场景中会非常吃力。

4.3 渲染流水线与重排重绘：为什么大数据表格会卡

浏览器原理部分的题目，核心围绕一个场景：给一个展示上万行数据的表格做性能优化，你会怎么做？这个场景设置得非常贴近他们自己的业务，因为AI平台里的数据标注、结果展示、指标看板，动不动就是几万甚至几十万条数据。

这类题的高分答案，通常从三个层面展开：

第一层是渲染层面。理解浏览器的渲染流水线：HTML解析成DOM树，CSS解析成CSSOM树，两者合并成渲染树，再进行布局计算和绘制。如果数据量大，直接填充DOM会导致布局计算量巨大，所以要用虚拟滚动技术，只渲染可视区域内的行，而不是渲染全部数据。

第二层是更新层面。重排是会导致整个文档流重新布局的操作，比如修改元素的宽度、高度、位置；重绘是重新绘制外观，比如修改颜色、背景。重排必然导致重绘，而重绘不必然导致重排。在数据密集型场景中，频繁操作DOM属性会引发大量重排，解决思路是批量修改DOM、使用DocumentFragment、或者把频繁变化的样式移到独立图层上。

第三层是数据层面。即使只渲染可视区域，如果每次滚动都要重新创建所有DOM节点，性能依然很差。正确做法是节点复用：用一个节点池，滚动时只修改节点内容，而不是新建和销毁节点。这是虚拟滚动实现的核心。

这道题没有标准答案，但你回答的深度直接反映你是否有过真实的大规模数据渲染经验。纯业务型前端可能一辈子都碰不到这种场景，但对做数据产品的团队来说，这是日常挑战。

4.4 关于CSS变量和现代布局方案的冷门追问

卷子里还有一道关于CSS变量的题：定义变量用--变量名，读取用var(--变量名)，变量会继承，也可以在运行时通过JavaScript修改。这道题本身不难，但它引出了一个更有价值的追问：CSS变量和预处理器变量（如SCSS变量）的区别是什么？

答案是：SCSS变量是编译期的，编译完成后就不存在了，所以无法在运行时动态修改；CSS变量是运行时的，可以直接在浏览器里通过document.documentElement.style.setProperty('--xxx', value)修改，并且修改后所有引用该变量的元素会同步更新。这在做主题换肤功能时是非常好用的方案。

这个知识点，单看试卷它只是一个几分的填空题，但它背后连接的是"如何在不刷新页面的情况下切换整套主题"这种实际工程需求。笔试的意义就在这：通过一个小的知识点，判断你是否真正做过相应的工程实践。

5. 框架与工程化：Vue考点居多，但需求是"理解设计"而非"背API"

5.1 Vue响应式原理：从Object.defineProperty到Proxy

2020年的前端笔试，Vue 2还是主流，所以框架题集中在Vue 2的响应式原理上。但第四范式的题问得比较有层次，从简单到复杂分了三步：

第一步：Vue 2的响应式原理是什么？标准回答是：Vue 2遍历data对象的每一个属性，用Object.defineProperty把它们转换成getter和setter。在组件渲染时，如果读取了某个属性，就会触发getter并收集依赖；后续如果修改了这个属性，就会触发setter并通知依赖更新。

第二步：为什么Vue 3要改成Proxy？因为Object.defineProperty有几个局限性：它只能代理对象上已有的属性，新增属性和删除属性都无法被拦截，所以Vue 2才需要提供Vue.set和Vue.delete来处理这类操作。而Proxy可以拦截整个对象上的所有操作，包括属性新增、删除、in操作符等，更全面。同时，Proxy的性能在某些场景下更好，因为它不需要遍历对象的每个属性，只在访问时进行拦截。

第三步：给你一段代码，问你Vue 2中它是否能正确触发更新？代码如下：

data() { return { user: { name: 'tom' } }; }, methods: { updateUser() { this.user.age = 20; } }

答案是不能。因为age属性在初始化时并不存在，Object.defineProperty没有对它做过响应式处理，所以给user新增age属性不会触发视图更新。要修复这个问题，需要用this.$set(this.user, 'age', 20)。追问：$set的底层原理是什么？答案：如果目标对象是响应式对象，且该属性不是已有属性，$set会用Object.defineProperty为它添加响应式定义，并手动触发依赖通知。

这道题层层递进，从概念到应用再到原理，几乎把"背面试题答案"的同学全部过滤掉了。只背"Vue是数据驱动"这种话的，过不了第二步和第三步。

5.2 Vue生命周期与nextTick：数据更新后DOM什么时候变？

框架题里还有一道生命周期相关的问题：在created生命周期里修改数据，DOM会立即更新吗？

答案是不会。created阶段组件实例已经创建，但还没挂载到DOM上，此时修改数据，Vue会把它放进异步更新队列，等待下一个nextTick时统一更新。这里的核心是Vue的异步更新机制：它不会在每次数据变化时都同步更新DOM，而是把所有的数据变化收集到一个队列里，然后在同一事件循环中批量执行DOM更新。

这道题的延伸考点是$nextTick的用法。它接收一个回调函数，在DOM更新完成后执行。如果你在修改数据后立即读取DOM的尺寸或位置，得到的一定是旧值。正确做法是在$nextTick回调里读取。这个知识点的应用场景很多，比如获取一个由v-if控制渲染的元素的宽度，或者在下一次渲染后操作某个刚出现的DOM节点。

5.3 组件通信：备选方案与原理都要能说清楚

Vue组件通信是框架题的常客，这套题里考察的是多种通信方式的对比。题目要求写出至少三种父子组件通信方案，并说明各自的适用场景。常见的答案包括：

• props和emit：适用于父子组件之间传递数据和触发事件，是最基础的通信方式。
• $refs：父组件通过ref直接调用子组件的方法或访问子组件的数据，适合用于子组件暴露方法的场景。
• provide/inject：适用于祖先组件向所有后代组件注入依赖，跨层级传递数据，不适合做响应式数据管理的场景。
• Event Bus：使用一个空的Vue实例作为事件总线，适合非父子关系的组件间通信，但事件多了容易混乱，不好维护。
• Vuex：适用于跨多个组件共享复杂状态，配合devtools调试更方面，但要注意避免过度使用。

一般同学能写出这五种就差不多了，但这类题目真正想考察的是你什么时候不用Vuex、什么时候不能不用Vuex、甚至用过provide/inject的隐性风险：它不是响应式的，除非传入的是一个响应式对象。这种对细节的把控，决定了面试官是把你当"会写Vue的"还是"理解Vue的"。

5.4 工程化：webpack的loader和plugin区别，以及代码分割思路

工程化部分的题目，一是问loader和plugin的区别，二是问如何优化打包体积。这道题的价值在于，它要求你不仅要理解webpack的配置项，还要能解释webpack的工作流程。

Loader和Plugin的核心区别是：loader是转换器，它把一种模块的源码转换成另一种模块的源码，比如babel-loader把ESNext转成ES5，css-loader处理CSS文件中的@import和url()。Plugin是扩展器，它在webpack构建流程的特定阶段执行额外的任务，比如HtmlWebpackPlugin在构建结束后生成HTML文件并自动注入打包产物，MiniCssExtractPlugin将CSS从JS中抽离成独立文件。

进一步追问：为什么是loader先执行、plugin散布在整个流程中？因为webpack的本质是一个模块打包器，它需要先把各种类型的文件统一转换成它能理解的JS模块，才能进行依赖分析和打包。loader处理"如何读取和转换文件"，plugin处理"什么时候做什么额外的事情"。能把这个逻辑讲清楚，说明你真正理解webpack的设计思路，而不是只会配一个vue.config.js。

代码分割的优化思路，我当时答的是：用SplitChunksPlugin把公共依赖提取到单独chunk中，用动态import()将路由页面拆分成按需加载的模块，再把框架类库（如Vue、Vue Router）单独打成一个vendor包，利用浏览器缓存减少重复下载。这个方案在面试官追问"具体怎么配置"时也完全能展开，不会露馅。

6. 算法题的实战应对：如何在半小时内拿满分数

6.1 高频题：数组去重、二叉树遍历、LRU缓存

算法题是这套笔试题里占比最重的部分，也是拉开分数差距的关键。我当时遇到的算法题主要有三类：数组去重、二叉树遍历、LRU缓存设计。

数组去重题比较简单，但要注意不能只写Array.from(new Set(arr))就结束，因为出题人会追问：如果数组里有对象，Set能去重吗？答案是不能，因为Set去重用的是同值零算法，对于引用类型，只有引用完全相同才会被认为是重复。面试官想听的是对去重原理的理解，而不是API的调用。

二叉树遍历的题目比较常规，但要求是写非递归版本。中序遍历的非递归实现需要显式维护一个栈：

function inorderTraversal(root) { const result = []; const stack = []; let current = root; while (current !== null || stack.length > 0) { while (current !== null) { stack.push(current); current = current.left; } current = stack.pop(); result.push(current.val); current = current.right; } return result; }

这道题的核心在于理解"先一路向左入栈，弹出访问，再转向右子树"这个循环过程。如果你平时只写过递归版本，笔试现场临时想非递归版本，压力会非常大，所以这类经典算法题需要在考前就做好模板化的准备。

LRU缓存设计题考察的是你的工程设计能力。它要求实现一个get和put方法，当缓存容量满时，淘汰最久未被使用的数据。这道题的设计要点是：用HashMap实现O(1)的读取，用双向链表来维护数据的访问顺序。每次get时，如果存在数据，把节点移动到链表头部；每次put时，如果不存在数据且缓存已满，移除链表尾部的节点，再插入新节点到头部。

6.2 做题策略：先写出暴力解，再优化

很多人笔试挂掉，不是不会做算法题，而是把时间卡在"想一步到位写出最优解"上。我的经验是，笔试先别急着写最优解，先用最直接、最不容易出错的暴力解法把题目过了，拿到基础分数，再回来做优化。

比如LRU缓存，如果你第一反应是用Map加数组维护顺序，虽然时间复杂度不是最优，但代码逻辑清晰，不容易写错。等你在暴力解的基础上验证了思路，再有时间就去优化成HashMap加双向链表。笔试系统可不会因为你"差一点写出最优解"就给分，写对第一版比构思最优解更务实。

6.3 笔试实战中的常见失误与应对

我在那次笔试算法环节踩过两个坑，值得说出来给大家参考。

第一个坑是没审清题目对时间复杂度的要求就动手设计。LRU那道题如果一开始就用数组的find方法查找元素，时间复杂度是O(n)，虽然功能正确，但肯定拿不到这道题的满分。所以拿到题目先看有没有"要求在O(1)时间内完成"之类的限定词，有的话就要围绕这个约束选数据结构。

第二个坑是边界条件检查不完整。比如二叉树遍历时，如果根节点为空，应该返回空数组；LRU的get方法如果key不存在，应该返回-1。这些边界条件在笔试里往往占据大量测试用例，不写就是白丢分。

7. 复盘与秋招准备建议：从一套笔试题反推备考方向

7.1 从这套题看第四范式前端团队的关注点

整套卷子考下来，最大的感受是：这家公司的前端团队不是"业务驱动"的，而是"产品与体验驱动"的。他们对前端的要求不止是"实现页面"，而是"在复杂数据场景下高效地实现页面"。这从CSS计算题、浏览器渲染性能题、大数据列表优化题都能看出来。

另外一点，他们对工程化的重视程度比一般公司高。webpack的loader和plugin、代码分割、构建优化这些话题，如果只是会配脚手架是不够的，你得知道构建链路里每一步在做什么。这不是面试官为难你，而是他们的产品里确实存在大量需要精细控制构建过程的场景。

7.2 给准备前端秋招笔试的通用建议

结合这次笔试经历，我整理了三条对多数公司笔试都有用的建议：

第一，基础题一定要建立"执行过程推演"的习惯。别只看代码的输出结果，要自己一步一步推演变量、作用域、调用栈、事件队列的变化。能用纸笔画出来，才说明真懂了。

第二，算法题要准备"模板"。二叉树的前中后序遍历、层序遍历、DFS、BFS、快排、递归转非递归，这些是高频中的高频，考前最好能默写出来。笔试的时间压力很大，不要指望现场推导。

第三，框架题不要只背API，要理解设计动机。比如Vue为什么用数据驱动、为什么需要异步更新、为什么模板编译器和运行时分离。追问一个"为什么"，往往就能分辨出你是背的还真的实践过。

7.3 笔试结束后的复盘方法

笔试结束并不代表这个环节就结束了，及时复盘才是把笔试价值最大化的方式。我当时把每一道做错的题、蒙对的题都整理到一个文档里，标注出错因和正确思路。之后每次面试前翻一遍，比刷新题还有用——因为自己的错题记录的是真实的思维盲区，针对性极强。

复盘时还要注意一个点：有些题你虽然做对了，但用的方法不一定是最优解。比如深拷贝那道题，如果你只是自己写了一个没用WeakMap的版本，虽然测试用例可能过了，但面试官在后续面试中追问"如果对象循环引用怎么办"时，你可能就答不上了。所以复盘时，也要回头审视自己做对的题，看看有没有更好的解法，尽早补齐盲区。

7.4 我自己踩过的一个比较惨的坑

最后分享一个真实的教训。我在那次笔试里，有一道关于事件循环的代码题，第一遍输出顺序写对了，但复查时又改错了——我把async1 end和promise2的顺序改反了。原因是我在复查时过度依赖记忆中的"await是异步的，所以async1 end一定最后输出"这个错误直觉，反而推翻了自己最初基于推演得到的正确结果。

这个经历让我养成了一个习惯：遇到事件循环、Promise、async/await这类题目，复查时不再靠"我觉得"，而是重新走一遍入队顺序的推演。如果推演结果和之前一致，就坚决不改。在笔试这种环境下，直觉有时候比记忆可靠，而基于规则的推演又比直觉可靠。

希望这篇复盘能帮你少走一些弯路。第四范式的笔试难度在当年算中等偏上，但它的考点结构其实非常典型，认真吃透这套题的底层逻辑，对你准备任何一家公司的前端秋招笔试都有帮助。