我去年秋招时拿到过酷家乐的笔试邀请当时选的也是前端方向。这套B卷做完之后印象挺深和一般刷题网站上的前端题不太一样它明显是围绕设计工具类Web应用这个业务场景来出题的。卷子里没有太多死记硬背的概念填空反而很看重你能不能把JavaScript的底层机制、浏览器渲染逻辑和实际业务场景串起来。这篇文章结合我的回忆和考点梳理把B卷里最有代表性的几类题目做个深度拆解顺便聊聊每道题背后真正想考察的能力。1. 这套B卷到底在考什么从酷家乐的用人画像说起1.1 为什么B卷和A卷的侧重点不一样酷家乐校招的前端笔试试卷分了好几套A卷和B卷的差异不在于难度而在考察方向。A卷更偏向常规Web应用开发比如后台管理系统、电商前台这类业务的通用技术栈。B卷则明显偏向图形渲染、Canvas性能优化、工程化基建这些方向这和酷家乐的核心业务——云设计工具、家装效果图实时渲染——有直接关系。从B卷的题目分布来看JavaScript语言基础占了大概三成浏览器原理和性能优化占了两成框架和工程化占了两成剩下三成是手写代码题和开放设计题。整体感觉是它不希望你只会用框架写页面更希望你有扎实的语言功底和性能敏感度。因为在酷家乐的实际业务里一个户型图的加载可能要处理上万条线段数据一次渲染性能不过关用户那边就是明显的卡顿这种问题靠框架层面是解决不了的。1.2 从题目反推酷家乐前端团队的日常判断一家公司的笔试好不好就看它的题和业务是否匹配。B卷里有几道题我印象很深一个是关于大文件上传的一个是关于Canvas离屏渲染的还有一个是设计一个组件库的API。这三道题几乎就是酷家乐前端日常工作的缩影。酷家乐大量业务涉及设计师上传户型图、素材包这些文件动辄几十上百MB所以大文件上传必须做切片和断点续传。Canvas渲染题更不用多说家装效果图编辑器里所有的户型、家具、墙地顶全部基于Canvas绘制性能优化是核心话题。组件库API设计题想考察的是你在工程化环境里的抽象能力——酷家乐内部有成百上千个业务页面没有一个好用的组件库迭代效率会非常低。所以看这套卷子表面是做题其实是在回答一个问题你能不能上手做酷家乐的业务。这也是我把它单独拿出来复盘的原因——它的题目设计和业务关联度确实很多大厂都没做到。2. JavaScript核心机制题闭包、作用域与异步的糅合陷阱2.1 一道把闭包和循环绑定揉在一起的经典题B卷开始部分的选择题和填空题里有不少JS基础但真正有意思的是后面的大题。有一道题给了一段代码大概是这样一个场景页面上有三个按钮点击之后分别输出对应的编号要求用for循环给每个按钮绑定事件。题目给了四种写法问你哪一种能正确输出0、1、2并且要解释为什么。这道题看起来是老生常谈的循环中var声明变量导致闭包共享引用问题但它比普通面试题多挖了一层它让你用块级作用域、立即执行函数、事件委托三种方式分别解决然后比较它们的差异。很多人第一反应是直接写let这当然对但题目追问的是如果必须用var在ES5环境下怎么写这个问题的价值在于它考察的不是你会不会用let而是你理不理解闭包的本质——函数记住的是变量的引用而不是变量的值。标准答案是立即执行函数创建一个新的函数作用域每次循环把i作为参数传进去形成独立副本for (var i 0; i 3; i) { (function(index) { btnList[index].addEventListener(click, function() { console.log(index); }); })(i); }我在B卷里写完后还补充了一句事件委托其实是最优解因为不管按钮增删都不需要重新绑定。把三个按钮的父容器绑定监听通过event.target判断点击的是哪个按钮再取编号这样性能更好也完全避开了闭包陷阱。不知道阅卷的人会不会注意这个补充但我觉得这道题想考察的绝不只是闭包而是你在真实业务里的最优解意识和性能意识。2.2 Promise并发控制的变体考察从手写到场景应用另一道让我印象深刻的题是关于Promise的但出题方式很活。它没有让你直接背Promise的API而是给了一个业务场景页面上需要上传三张户型图素材图每张图要经过压缩、上传、生成缩略图三个步骤并且希望这三张图的处理相互独立、并发执行但必须在所有图片处理完成后统一更新页面状态。问你用Promise.all、Promise.allSettled还是别的什么并解释原因。我选了Promise.allSettled因为三张图的上传过程中任何一张失败都不应该影响其他图片的处理结果。Promise.all是只要有一个reject就整体失败这在批量上传场景里不友好——一张图传失败了另外两张成功的结果也没了。Promise.allSettled会等待所有Promise都出结果然后通过判断每个结果里的status字段来区分成功和失败更适合这种部分失败也要保留成功结果的业务场景。题目后面还有个小追问如果要求控制并发数最多同时只能有两个上传请求在跑怎么写这就是典型的asyncPool并发池问题了。我当时是手写了一个简单的递归式实现async function asyncPool(poolLimit, tasks) { const results []; const executing new Set(); for (const task of tasks) { const promise task().then(res { results.push(res); executing.delete(promise); }); executing.add(promise); if (executing.size poolLimit) { await Promise.race(executing); } } await Promise.allSettled(executing); return results; }这里有个细节值得展开说说。很多人抄过这个模板但不理解为什么要用Promise.race。Promise.race的作用是等最快的那个完成当并发数达到上限时新任务并不能立刻执行必须先等待某个任务结束腾出位置。race只需要等待最快的一个Promise落定就行不会阻塞在这批任务里最慢的那个上所以效率最高。如果用Promise.all去等那就得等全部任务跑完才能开始下一批并发控制就失去意义了。2.3 原型链与继承的另类出题方式B卷对原型链的考察也很有趣出了一道改错题给了一个用构造函数实现继承的写法里面有两个地方写得不严谨让你找出来。这种考察方式比说说原型链是什么高级在哪儿呢它更像code review要求你真正理解原型链的运行机制。原题大概是这样function Animal(name) { this.name name; } Animal.prototype.sayName function() { console.log(this.name); }; function Dog(name, breed) { Animal.call(this, name); this.breed breed; } Dog.prototype new Animal(); Dog.prototype.constructor Dog; Dog.prototype.bark function() { console.log(wang wang); };两个问题第一Dog.prototype new Animal()创建了一个Animal实例但这个实例本身就有name属性undefined会给Dog.prototype带上一个没意义的name不如改成Dog.prototype Object.create(Animal.prototype)只继承原型方法不实例化父类。第二改了prototype之后Dog.prototype.constructor已经指向了Animal如果不手动赋值回Dog那么通过new Dog()创建出来的实例的constructor就会错误地指向Animal后面做类型判断时会出bug。这道题想考察的是你真的理解prototype、constructor、__proto__三者的指向关系还是仅仅背过寄生组合式继承是最优解这句话。这两种状态在笔试里的差别从答案的表述中一眼就能看出来。3. 浏览器与渲染原理题从URL输入到页面展示的完整链路3.1 一道需要分阶段作答的流程题B卷里有道题是论述题在浏览器地址栏输入一个网址按下回车到页面完整展示出来中间经历了哪些过程。这道题校招笔试里非常常见但B卷的评分标准明显更严格——你只回答DNS解析、TCP连接、HTTP请求、渲染这几个词是不够的它要求展开说明每个阶段的关键细节。我的答题思路是把整个过程拆成两大块网络通信链路和浏览器渲染链路。网络通信链路从DNS解析开始然后到TCP三次握手再到HTTP请求发出、服务器响应返回。这里我详细写了TCP握手为什么是三次而不是两次——核心是防止历史重复连接初始化造成混乱。渲染链路则从HTML解析成DOM树、CSS解析成CSSOM树开始然后合并成渲染树再做布局计算和绘制。为了体现深度我特意补充了几个容易被忽略的细节。一是DNS解析是分级的先查浏览器缓存再查系统缓存再查本地hosts文件最后才走递归查询到根域名服务器这个过程是有时间成本的所以HTTP缓存策略里有个DNS Prefetch的优化手段。二是在现代浏览器里DOM树构建和CSSOM树构建是并行进行的JavaScript的加载和执行会阻塞HTML解析所以要合理放置script标签的位置。三是渲染进程里还有个合成线程它负责把不同的图层合成最终画面transform和opacity的动画之所以高效是因为它们能触发布局和绘制之外的合成步骤。3.2 从渲染原理追问到的性能优化方案这道题最狠的地方在于后面还有一问根据你上面写的渲染链路分析白屏时间过长可能的原因并给出优化方案。其实这就是在考察你能不能用渲染原理指导实际开发。我记得自己当时从渲染链路出发反推了几个关键阻塞点。DNS解析慢——那就用dns-prefetch预解析。TCP连接建立慢——那就用preconnect提前建立连接。HTML解析被JavaScript阻塞——那就把script标签加defer或async或者直接放到body底部。CSSOM构建被过大的CSS文件拖慢——那就做CSS代码分割首屏只加载关键CSS剩下的异步加载。但我觉得整道题最出彩的补充是白屏时间不完全由加载性能决定还可能和渲染性能有关。如果HTML和CSS加载完成后JavaScript里有一段非常耗时的同步计算比如在onload里直接跑一个大数据量的遍历主线程被占住首帧照样出不来。这种情况要交给Web Worker处理把计算任务从主线程挪走让主线程专注于渲染。Web Worker这个点其实我在做题时就想到会是一个好的补充方向因为酷家乐的业务确实用到这个技术。像大户型数据解析、渲染参数计算这些CPU密集型的任务放在主线程上会直接把UI拖到不可交互的状态只能靠Worker在后台单独跑。热搜词里也有前端使用worker上传大文件这说明酷家乐的面试官大概率会对这个技术细节感兴趣。我干脆在答题末尾追了一句如果有性能指标上报系统优先观测DOMContentLoaded、First Contentful Paint和Time to Interactive这三个指标其中白屏问题主要看FCP。3.3 一道关于localStorage、sessionStorage与Cookie的对比题这套卷子里还有一道很基础的题目但被我小看了。它考的是三种浏览器存储方式的对比看起来没什么难度但它加了一个限制条件在浏览器标签页关闭之后、再次打开时哪些数据还在哪些不在了这个问题的陷阱在于浏览器崩溃后的sessionStorage恢复机制。正常情况下sessionStorage的生命周期是标签页关闭就清除但如果浏览器是崩溃或者被强杀重新打开会话时Chrome可能会尝试恢复之前的会话状态sessionStorage就有可能被保留。这不是标准规定的行为而是浏览器层面的恢复策略。所以严谨的回答是规范层面关闭标签页即清除但异常退出时存在恢复的可能性。我建议在做这套卷的存储类题目时把场景和API分开回答先答规范层面的定义再答实际浏览器环境下的表现最后补充适用的业务场景。比如Cookie适合做登录态识别因为它每次请求都会自动携带但容量只有4KB左右localStorage适合存一些不敏感的业务配置容量通常有5MB但它只能在浏览器端读写无法在请求头里自动携带sessionStorage适合在单个标签页内的多页面间共享临时状态。这样一来答案的层次就会比单纯对比表格丰富很多。4. 框架应用题Vue/React的异同与源码级理解4.1 Vue响应式原理为什么值得展开写B卷里明确写了一句以下框架题Vue和React任选其一作答。我选的是Vue因为它在我当时的知识储备里更完整。题目问的是Vue 2里data属性发生变化后页面是怎么自动更新过来的这个更新过程分几个步骤我知道标准答案是三大块Object.defineProperty做依赖收集、Watcher监听变化、更新时触发render函数重新执行。但B卷的答案如果想拿高分不能只答这三条。我把它拆成了更细的链路初始化时Vue会对data里的每个属性调用Object.defineProperty把属性转为带有getter和setter的访问器属性。当组件渲染时会读取模板里用到的数据触发getter这时就会做依赖收集——把当前组件的渲染Watcher收集进这个属性的依赖列表里。当数据变化时触发setter通知所有依赖了该属性的Watcher去更新。Watcher收到通知后不会立即执行渲染而是被推进一个队列里在下一个事件循环的tick时统一执行这个机制叫异步更新队列。这里有个值得深挖的细节为什么需要异步更新队列。如果数据在同一个事件循环里连续被改了十次每次都立刻触发渲染那就是十次无意义的性能开销。Vue的做法是把所有变化收集到一个队列里去重后只执行一次更新的渲染流程。这就是为什么修改完data后立刻读取DOM拿不到更新后的值必须用Vue.nextTick因为DOM的更新是异步批量执行的。4.2 Vue 3的Proxy和Vue 2的defineProperty优劣对比B卷里还有一道对比题问Vue 3的响应式原理和Vue 2有什么区别为什么Vue 3要把Object.defineProperty换成Proxy。这道题考察的是你对技术演进的理解深度而不是让你背Vue 3新特性列表。我的回答从三个方面展开。第一Object.defineProperty只能监听对象的已有属性对于新增属性和删除属性是无感知的所以Vue 2才需要Vue.set和Vue.delete这类额外的API。Proxy则不一样它是代理整个对象不管属性是新增、删除还是修改都能被拦截到从语言层面解决了这个问题。第二Object.defineProperty需要递归遍历对象的每个属性来定义访问器属性对象层级越深初始化的性能开销越大。Proxy虽然也需要递归处理嵌套对象但它是惰性的——只有在真正访问到某个嵌套对象时才对这个对象做响应式代理初始化性能明显优于Vue 2。第三Proxy还能拦截更多操作比如in操作符、for...in循环、函数调用等等。这些是Object.defineProperty完全做不到的。所以在Vue 3里响应式的边界情况比Vue 2少得多心智负担也更轻。我把这个对比做成了一张表放在答题区特性Vue 2的definePropertyVue 3的Proxy监听新增/删除属性不生效需要额外API原生支持嵌套对象响应式递归初始化性能开销大惰性代理按需处理支持的拦截操作get/set等有限操作get/set/deleteProperty/has等十余种对数组的处理需要重写数组方法原生拦截数组索引和长度变化兼容性IE9不支持IE这道题其实还想考察你是不是愿意花时间去关注框架底层的变化。学Vue不是只学API更要理解它为了解决什么问题而设计。我当时在答案里多写了这句话后来我觉得这可能是加分项。4.3 框架题里的场景设计考察方向这套卷的框架题有个很明显的特色它不会让你单纯背API而是给你一个具体场景问你怎么实现。我记得有一道题是这样的在Vue项目里有一个全局的loading状态要求在任意组件里都能方便地修改它的值同时页面上的loading组件要能响应变化你会用什么方案常规答案是Vuex或者Pinia因为全局状态管理本身就是干这个的。但B卷的高分答案应该再往深走一步为什么要用状态管理库其实核心是为了解决两个问题。第一是把状态从组件里抽离出来形成全局单例组件之间共享数据就不再需要通过props层层传递或者通过事件层层emit。第二是让状态的变化可以追踪Vuex里的mutation和Pinia里的action都做了集中管理数据流的来源和去向是清晰的这在团队协作里特别重要。但更高级的回答是除了状态管理库还可以利用Vue的provide/inject机制来做依赖注入适合跨层级组件共享状态的场景。比如根组件provide一个loading相关的reactive对象后代组件直接inject进来使用这样就绕过了中间层组件必须手动透传props的问题。provide/inject和Vuex的组合使用在真实的业务代码里非常常见——一部分是页面级的局部共享状态用provide/inject就够轻量一部分是应用级的全局状态再做状态管理。这个思路我在后面的开放题里也用到了一部分算是B卷框架题的一个隐藏主线。5. 手写代码题逐题拆解从实现到优化5.1 防抖和节流实现不难难的是边界条件手写防抖和节流基本上是前端笔试的标配了B卷当然没落下。但它的追问方式不一样它给了两个业务场景让你判断分别用防抖还是节流并实现。场景一是搜索框输入关键字实时请求后端接口场景二是页面滚动时记录滚动位置到本地存储。这题我先给的结论是搜索用防抖滚动用节流。防抖的核心思路是频繁触发时只在最后一次触发之后等待一段时间再执行因为用户输入过程中每一次按键都是有效的但真正希望发请求的时刻是用户停顿下来之后节流的核心思路是固定时间内只执行一次因为滚动事件里如果也要等用户完全停下来才记录位置用户中途刷新页面就会丢失最新位置节流保证即使一直在滚动也会每间隔一段时间记录一次。实现时我给的是带立即执行参数的标准版本function debounce(fn, delay, immediate false) { let timer null; return function(...args) { const context this; if (timer) clearTimeout(timer); if (immediate) { const callNow !timer; timer setTimeout(() { timer null; }, delay); if (callNow) fn.apply(context, args); } else { timer setTimeout(() { fn.apply(context, args); timer null; }, delay); } }; }防抖有个很坑的边界条件如果用户一直不停触发呢标准防抖会导致回调永远不执行。所以很多实际项目里会加一个maxWait参数保证在N毫秒内至少执行一次。Vue的源码里debounce实现就考虑了这个点它内部用了一个timerExpired函数递归地设置定时器。我在B卷里额外提了一句这个优化虽然没有展开写但至少让阅卷老师知道我不是只会背书。这题想告诉我们的是手写题不是把代码默写出来就完事关键要证明你能思考到别人容易忽略的边界情况。5.2 深拷贝手写的层次和边界B卷的深拷贝题也有它的要求。它给的题干是请你手写一个深拷贝函数要求能处理数组、对象、日期、正则表达式并且要防止循环引用。基础版本大概是这样function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) { return target; } if (target instanceof Date) { return new Date(target.getTime()); } if (target instanceof RegExp) { return new RegExp(target.source, target.flags); } if (map.has(target)) { return map.get(target); } const cloneTarget Array.isArray(target) ? [] : {}; map.set(target, cloneTarget); for (const key in target) { if (Object.prototype.hasOwnProperty.call(target, key)) { cloneTarget[key] deepClone(target[key], map); } } return cloneTarget; }这里有哪些点是加分项首先是日期和正则的处理很多人的手写深拷贝只考虑对象和数组遇到Date就会退化成普通对象复制出来的值是完全错误的。其次是循环引用如果对象里存在a.self a这样自引用没有WeakMap记录的话会无限递归导致栈溢出。第三遍历对象时要用hasOwnProperty做判断避免把原型链上的属性也复制进来。再往深一点还能考虑Symbol键名、Map和Set等类型但B卷的篇幅和时限决定了这类题的答法不是写得越长越好而是该覆盖的点都覆盖到且没有严重bug。我给这道题的建议是先写主干逻辑基本类型判断、对象数组递归、循环引用处理再补充特殊类型Date、RegExp如果还有精力再扩展Map和Set。这样就算没写全核心分也拿到了。5.3 手写Promise.all考察异步和错误处理的结合B卷有一道手写Promise.all的题目。这个题其实在2020年前后就是前端面试高频题2026年的面试依然是重点只是要求更高了。它考的是你对Promise机制的理解——静态方法怎么和构造函数配合、内部如何同步收集结果、错误如何快速失败。我当时写的版本Promise.myAll function(promises) { return new Promise((resolve, reject) { const results []; let completed 0; const total promises.length; if (total 0) { resolve(results); return; } for (let i 0; i total; i) { Promise.resolve(promises[i]).then(value { results[i] value; completed; if (completed total) { resolve(results); } }).catch(err { reject(err); }); } }); };这个实现有几个值得注意的地方。第一结果数组是通过下标赋值results[i]而不是用push为什么因为Promise的完成顺序是并发的先返回的不一定是第一个元素用下标才能保证结果顺序与传入顺序一致。用push的话结果顺序就会乱掉。第二空数组要直接resolve这个边界很多人会漏。第三任何一个Promise失败就整体reject这是Promise.all的快速失败特性但同时也就意味着其他还在执行的Promise的结果会被丢弃——这就是为什么我在前面的并发上传场景里更倾向于allSettled。这道题的延伸知识点是手写Promise.allSettled和手写Promise.race。B卷虽然只考了all但如果平时能多练几种静态方法的实现考场上万一遇到换皮题就不慌了。6. 编程题思路复盘从组件库设计到大文件上传6.1 开放设计题如果让你设计一个组件库的API你会考虑什么B卷压轴的开放题是如果有足够资源让你从零开始设计一个前端组件库你的API设计思路是什么。这个题没有标准答案我甚至觉得它不完全考技术还在考你有没有做过项目、有没有思考过工程化。我的回答打了一个非常简单的框架稳定、一致、可扩展。稳定指的是API不随意变化一个组件库如果发布后频繁调整props的语义会给使用者带来巨大的维护成本。所以组件props的命名要一致比如visible和open这两种表达方式必须选用一种并贯彻到底。显示和隐藏的回调要么统一叫onClose要么统一叫onCancel不能这个组件用这个、那个组件用那个。一致指的是交互和视觉风格统一按钮的尺寸、输入框的状态、弹窗的层级都应该有统一的设计规范和token体系。可扩展指的是组件要支持自定义插槽或者自定义渲染函数让使用者在不需要改库源码的情况下扩展功能。我额外提到了TypeScript和单元测试在组件库建设里的重要性。TypeScript的泛型机制能让props的约束在编译阶段就被发现单元测试则至少保证Button的点击、禁用、加载等基本交互不会在回归中出现问题。最后我还提了一嘴如果团队工作流允许组件库应该配套提供独立的文档站点和Demo示例一个没有规范文档的组件库在团队里很难被推广。这道题其实就是考察你会不会从0到1搭东西并且考虑到它被其他人使用时的体验。6.2 工程化场景题大文件上传的切片与断点续传B卷里有一道我完全没想到会出现的笔试题——大文件上传。它问前端要上传一个大文件可能是几百MB甚至1GB直接form提交会有什么问题你会怎么设计一个可用的上传方案这明显是酷家乐业务里设计师上传施工图、全景图的真实场景。官方服务条款先不说单从纯前端角度这个题能考察的点非常密集。第一步要答直接整包上传的问题包括请求超时、内存占用过高、失败后只能从头再传、服务端接收超大请求容易受到限制。但这些问题的根源都指向同一个词——一次性传输太大所以拆分的思路是自然的选择。第二步要答把大文件切成固定大小的分片比如每片5MB或10MB切完之后并发上传。这个方案的好处是失败后只需要重传失败的分片不用整个文件重来。关键点在于切片前要为整个文件计算一个唯一的标识可以用文件名的hash加文件大小的组合更稳妥的是借助spark-md5这类库计算文件的hash值作为唯一ID。因为文件内容不变hash就不变下次重新上传时服务端能根据这个ID判断哪些分片已经传过了跳过已传的分片只传缺失的这就是断点续传的核心。第三步要答上传过程中网络断了或者用户手动取消前端怎么恢复。方案是本地记录已上传分片的状态重新唤起上传时先向后端查询该文件的已传分片列表把没传的补上即可。再用Web Worker去处理文件切片和hash计算这种CPU密集任务避免计算hash时页面卡死。我在这里又补充了一个细节并发上限不能太大并发数为3到5比较合适。并发太高会导致浏览器和服务端的连接数压力过大单个分片反而变慢。实测下来5MB的分片大小配合3个并发在绝大多数网络环境里表现稳定。这类题不背答案平时真的写过上传功能的人才能答得这么细。这也是我复盘之后对B卷的整体印象所有开放题都指向一个字——用。6.3 算法题的取舍与做题策略最后简单说说B卷里的算法题。酷家乐的前端卷算法比重不高但有一道我印象很深的字符串处理题。题目要求是给定一个由小写字母和数字组成的字符串按照数字在后、字母在前的规则重新排列并且字母部分保持原有顺序数字部分也保持原有顺序。这题的本质是稳定分区。最容易想到的是写两个循环一个筛字母一个筛数字两个结果拼起来时间复杂度O(n)空间复杂度O(n)。但也可以继续优化到原地操作用双指针做类似快排的partition但要注意稳定这个要求用双指针做原地交换一般会破坏稳定性所以更稳妥的做法是允许用额外空间。做这套卷的建议是不要在算法题上死磕太久。B卷的大头是基础题、框架题和手写题算法题只要能把最朴素的解法写出来、能运行、能讲清楚复杂度基本就可以了。真正拉开分数差距的是前面那些需要结合业务场景分析的题目。7. 这份B卷给准备校招的人的三点启示这套卷子做完复盘完我最想分享的还是那句老话笔试不是考察你会背多少知识点而是考察你在真实场景下能不能用这些知识解决问题。第一点启示要把知识点和业务场景绑定在一起复习。你在准备前端校招时只看防抖节流是什么是不够的得能想到它们在搜索提示、滚动加载这些场景里的位置只看Vue响应式原理的定义也没用得能画出一条数据变化到视图更新的链路图再解释为什么异步更新能带来性能收益。酷家乐B卷所有的题目都在做同一件事——逼你说清楚知识的来源和用途。第二点启示手写代码题不要只背模板。B卷里的深拷贝和Promise.all都是经典题目但如果你只是机械地把代码背下来它后面跟一个场景化的追问你就很难接得住。我建议每刷一个手写题都要问自己三个问题这段代码里哪些边界条件是容易遗漏的这段代码跑在真实业务里的哪个场景如果让我给它加一个新需求我要怎么改把这三个问题回答了这道题才算真正吃透。第三点启示选择对的方向比刷题数量重要。做酷家乐B卷之前先想一想这家公司是做什么的。云设计软件、WebGL渲染、户型图编辑、大量Canvas绘图、图片和材质文件的上传与处理——这些业务决定了它对前端的要求。你在准备它的笔试时与其刷一百道React组件写法不如认真研究Canvas性能优化策略、Promise并发控制、大文件上传这些和业务强相关的技术点。最后再分享一个小技巧笔试的时候遇到开放题别急着落笔先把答题框架在脑子里过一遍。很多开放题都可以用背景—矛盾—方案—关键细节这个结构来组织答案。比如大文件上传题背景是设计师要传大文件直接上传会超时失败矛盾是传输的不稳定性与文件体积大的冲突方案是切片、断点续传、Web Worker结合关键细节是hash标识、并发上限、失败重试。按这个结构答出来的东西得分一定比想到哪写到哪的答案高。这套卷子的复盘就到这里。如果你也在准备类似的前端校招希望这份拆解能帮你少走一些弯路。 酷家乐前端B卷深度复盘：JavaScript机制与渲染性能实战解析
我去年秋招时拿到过酷家乐的笔试邀请当时选的也是前端方向。这套B卷做完之后印象挺深和一般刷题网站上的前端题不太一样它明显是围绕设计工具类Web应用这个业务场景来出题的。卷子里没有太多死记硬背的概念填空反而很看重你能不能把JavaScript的底层机制、浏览器渲染逻辑和实际业务场景串起来。这篇文章结合我的回忆和考点梳理把B卷里最有代表性的几类题目做个深度拆解顺便聊聊每道题背后真正想考察的能力。1. 这套B卷到底在考什么从酷家乐的用人画像说起1.1 为什么B卷和A卷的侧重点不一样酷家乐校招的前端笔试试卷分了好几套A卷和B卷的差异不在于难度而在考察方向。A卷更偏向常规Web应用开发比如后台管理系统、电商前台这类业务的通用技术栈。B卷则明显偏向图形渲染、Canvas性能优化、工程化基建这些方向这和酷家乐的核心业务——云设计工具、家装效果图实时渲染——有直接关系。从B卷的题目分布来看JavaScript语言基础占了大概三成浏览器原理和性能优化占了两成框架和工程化占了两成剩下三成是手写代码题和开放设计题。整体感觉是它不希望你只会用框架写页面更希望你有扎实的语言功底和性能敏感度。因为在酷家乐的实际业务里一个户型图的加载可能要处理上万条线段数据一次渲染性能不过关用户那边就是明显的卡顿这种问题靠框架层面是解决不了的。1.2 从题目反推酷家乐前端团队的日常判断一家公司的笔试好不好就看它的题和业务是否匹配。B卷里有几道题我印象很深一个是关于大文件上传的一个是关于Canvas离屏渲染的还有一个是设计一个组件库的API。这三道题几乎就是酷家乐前端日常工作的缩影。酷家乐大量业务涉及设计师上传户型图、素材包这些文件动辄几十上百MB所以大文件上传必须做切片和断点续传。Canvas渲染题更不用多说家装效果图编辑器里所有的户型、家具、墙地顶全部基于Canvas绘制性能优化是核心话题。组件库API设计题想考察的是你在工程化环境里的抽象能力——酷家乐内部有成百上千个业务页面没有一个好用的组件库迭代效率会非常低。所以看这套卷子表面是做题其实是在回答一个问题你能不能上手做酷家乐的业务。这也是我把它单独拿出来复盘的原因——它的题目设计和业务关联度确实很多大厂都没做到。2. JavaScript核心机制题闭包、作用域与异步的糅合陷阱2.1 一道把闭包和循环绑定揉在一起的经典题B卷开始部分的选择题和填空题里有不少JS基础但真正有意思的是后面的大题。有一道题给了一段代码大概是这样一个场景页面上有三个按钮点击之后分别输出对应的编号要求用for循环给每个按钮绑定事件。题目给了四种写法问你哪一种能正确输出0、1、2并且要解释为什么。这道题看起来是老生常谈的循环中var声明变量导致闭包共享引用问题但它比普通面试题多挖了一层它让你用块级作用域、立即执行函数、事件委托三种方式分别解决然后比较它们的差异。很多人第一反应是直接写let这当然对但题目追问的是如果必须用var在ES5环境下怎么写这个问题的价值在于它考察的不是你会不会用let而是你理不理解闭包的本质——函数记住的是变量的引用而不是变量的值。标准答案是立即执行函数创建一个新的函数作用域每次循环把i作为参数传进去形成独立副本for (var i 0; i 3; i) { (function(index) { btnList[index].addEventListener(click, function() { console.log(index); }); })(i); }我在B卷里写完后还补充了一句事件委托其实是最优解因为不管按钮增删都不需要重新绑定。把三个按钮的父容器绑定监听通过event.target判断点击的是哪个按钮再取编号这样性能更好也完全避开了闭包陷阱。不知道阅卷的人会不会注意这个补充但我觉得这道题想考察的绝不只是闭包而是你在真实业务里的最优解意识和性能意识。2.2 Promise并发控制的变体考察从手写到场景应用另一道让我印象深刻的题是关于Promise的但出题方式很活。它没有让你直接背Promise的API而是给了一个业务场景页面上需要上传三张户型图素材图每张图要经过压缩、上传、生成缩略图三个步骤并且希望这三张图的处理相互独立、并发执行但必须在所有图片处理完成后统一更新页面状态。问你用Promise.all、Promise.allSettled还是别的什么并解释原因。我选了Promise.allSettled因为三张图的上传过程中任何一张失败都不应该影响其他图片的处理结果。Promise.all是只要有一个reject就整体失败这在批量上传场景里不友好——一张图传失败了另外两张成功的结果也没了。Promise.allSettled会等待所有Promise都出结果然后通过判断每个结果里的status字段来区分成功和失败更适合这种部分失败也要保留成功结果的业务场景。题目后面还有个小追问如果要求控制并发数最多同时只能有两个上传请求在跑怎么写这就是典型的asyncPool并发池问题了。我当时是手写了一个简单的递归式实现async function asyncPool(poolLimit, tasks) { const results []; const executing new Set(); for (const task of tasks) { const promise task().then(res { results.push(res); executing.delete(promise); }); executing.add(promise); if (executing.size poolLimit) { await Promise.race(executing); } } await Promise.allSettled(executing); return results; }这里有个细节值得展开说说。很多人抄过这个模板但不理解为什么要用Promise.race。Promise.race的作用是等最快的那个完成当并发数达到上限时新任务并不能立刻执行必须先等待某个任务结束腾出位置。race只需要等待最快的一个Promise落定就行不会阻塞在这批任务里最慢的那个上所以效率最高。如果用Promise.all去等那就得等全部任务跑完才能开始下一批并发控制就失去意义了。2.3 原型链与继承的另类出题方式B卷对原型链的考察也很有趣出了一道改错题给了一个用构造函数实现继承的写法里面有两个地方写得不严谨让你找出来。这种考察方式比说说原型链是什么高级在哪儿呢它更像code review要求你真正理解原型链的运行机制。原题大概是这样function Animal(name) { this.name name; } Animal.prototype.sayName function() { console.log(this.name); }; function Dog(name, breed) { Animal.call(this, name); this.breed breed; } Dog.prototype new Animal(); Dog.prototype.constructor Dog; Dog.prototype.bark function() { console.log(wang wang); };两个问题第一Dog.prototype new Animal()创建了一个Animal实例但这个实例本身就有name属性undefined会给Dog.prototype带上一个没意义的name不如改成Dog.prototype Object.create(Animal.prototype)只继承原型方法不实例化父类。第二改了prototype之后Dog.prototype.constructor已经指向了Animal如果不手动赋值回Dog那么通过new Dog()创建出来的实例的constructor就会错误地指向Animal后面做类型判断时会出bug。这道题想考察的是你真的理解prototype、constructor、__proto__三者的指向关系还是仅仅背过寄生组合式继承是最优解这句话。这两种状态在笔试里的差别从答案的表述中一眼就能看出来。3. 浏览器与渲染原理题从URL输入到页面展示的完整链路3.1 一道需要分阶段作答的流程题B卷里有道题是论述题在浏览器地址栏输入一个网址按下回车到页面完整展示出来中间经历了哪些过程。这道题校招笔试里非常常见但B卷的评分标准明显更严格——你只回答DNS解析、TCP连接、HTTP请求、渲染这几个词是不够的它要求展开说明每个阶段的关键细节。我的答题思路是把整个过程拆成两大块网络通信链路和浏览器渲染链路。网络通信链路从DNS解析开始然后到TCP三次握手再到HTTP请求发出、服务器响应返回。这里我详细写了TCP握手为什么是三次而不是两次——核心是防止历史重复连接初始化造成混乱。渲染链路则从HTML解析成DOM树、CSS解析成CSSOM树开始然后合并成渲染树再做布局计算和绘制。为了体现深度我特意补充了几个容易被忽略的细节。一是DNS解析是分级的先查浏览器缓存再查系统缓存再查本地hosts文件最后才走递归查询到根域名服务器这个过程是有时间成本的所以HTTP缓存策略里有个DNS Prefetch的优化手段。二是在现代浏览器里DOM树构建和CSSOM树构建是并行进行的JavaScript的加载和执行会阻塞HTML解析所以要合理放置script标签的位置。三是渲染进程里还有个合成线程它负责把不同的图层合成最终画面transform和opacity的动画之所以高效是因为它们能触发布局和绘制之外的合成步骤。3.2 从渲染原理追问到的性能优化方案这道题最狠的地方在于后面还有一问根据你上面写的渲染链路分析白屏时间过长可能的原因并给出优化方案。其实这就是在考察你能不能用渲染原理指导实际开发。我记得自己当时从渲染链路出发反推了几个关键阻塞点。DNS解析慢——那就用dns-prefetch预解析。TCP连接建立慢——那就用preconnect提前建立连接。HTML解析被JavaScript阻塞——那就把script标签加defer或async或者直接放到body底部。CSSOM构建被过大的CSS文件拖慢——那就做CSS代码分割首屏只加载关键CSS剩下的异步加载。但我觉得整道题最出彩的补充是白屏时间不完全由加载性能决定还可能和渲染性能有关。如果HTML和CSS加载完成后JavaScript里有一段非常耗时的同步计算比如在onload里直接跑一个大数据量的遍历主线程被占住首帧照样出不来。这种情况要交给Web Worker处理把计算任务从主线程挪走让主线程专注于渲染。Web Worker这个点其实我在做题时就想到会是一个好的补充方向因为酷家乐的业务确实用到这个技术。像大户型数据解析、渲染参数计算这些CPU密集型的任务放在主线程上会直接把UI拖到不可交互的状态只能靠Worker在后台单独跑。热搜词里也有前端使用worker上传大文件这说明酷家乐的面试官大概率会对这个技术细节感兴趣。我干脆在答题末尾追了一句如果有性能指标上报系统优先观测DOMContentLoaded、First Contentful Paint和Time to Interactive这三个指标其中白屏问题主要看FCP。3.3 一道关于localStorage、sessionStorage与Cookie的对比题这套卷子里还有一道很基础的题目但被我小看了。它考的是三种浏览器存储方式的对比看起来没什么难度但它加了一个限制条件在浏览器标签页关闭之后、再次打开时哪些数据还在哪些不在了这个问题的陷阱在于浏览器崩溃后的sessionStorage恢复机制。正常情况下sessionStorage的生命周期是标签页关闭就清除但如果浏览器是崩溃或者被强杀重新打开会话时Chrome可能会尝试恢复之前的会话状态sessionStorage就有可能被保留。这不是标准规定的行为而是浏览器层面的恢复策略。所以严谨的回答是规范层面关闭标签页即清除但异常退出时存在恢复的可能性。我建议在做这套卷的存储类题目时把场景和API分开回答先答规范层面的定义再答实际浏览器环境下的表现最后补充适用的业务场景。比如Cookie适合做登录态识别因为它每次请求都会自动携带但容量只有4KB左右localStorage适合存一些不敏感的业务配置容量通常有5MB但它只能在浏览器端读写无法在请求头里自动携带sessionStorage适合在单个标签页内的多页面间共享临时状态。这样一来答案的层次就会比单纯对比表格丰富很多。4. 框架应用题Vue/React的异同与源码级理解4.1 Vue响应式原理为什么值得展开写B卷里明确写了一句以下框架题Vue和React任选其一作答。我选的是Vue因为它在我当时的知识储备里更完整。题目问的是Vue 2里data属性发生变化后页面是怎么自动更新过来的这个更新过程分几个步骤我知道标准答案是三大块Object.defineProperty做依赖收集、Watcher监听变化、更新时触发render函数重新执行。但B卷的答案如果想拿高分不能只答这三条。我把它拆成了更细的链路初始化时Vue会对data里的每个属性调用Object.defineProperty把属性转为带有getter和setter的访问器属性。当组件渲染时会读取模板里用到的数据触发getter这时就会做依赖收集——把当前组件的渲染Watcher收集进这个属性的依赖列表里。当数据变化时触发setter通知所有依赖了该属性的Watcher去更新。Watcher收到通知后不会立即执行渲染而是被推进一个队列里在下一个事件循环的tick时统一执行这个机制叫异步更新队列。这里有个值得深挖的细节为什么需要异步更新队列。如果数据在同一个事件循环里连续被改了十次每次都立刻触发渲染那就是十次无意义的性能开销。Vue的做法是把所有变化收集到一个队列里去重后只执行一次更新的渲染流程。这就是为什么修改完data后立刻读取DOM拿不到更新后的值必须用Vue.nextTick因为DOM的更新是异步批量执行的。4.2 Vue 3的Proxy和Vue 2的defineProperty优劣对比B卷里还有一道对比题问Vue 3的响应式原理和Vue 2有什么区别为什么Vue 3要把Object.defineProperty换成Proxy。这道题考察的是你对技术演进的理解深度而不是让你背Vue 3新特性列表。我的回答从三个方面展开。第一Object.defineProperty只能监听对象的已有属性对于新增属性和删除属性是无感知的所以Vue 2才需要Vue.set和Vue.delete这类额外的API。Proxy则不一样它是代理整个对象不管属性是新增、删除还是修改都能被拦截到从语言层面解决了这个问题。第二Object.defineProperty需要递归遍历对象的每个属性来定义访问器属性对象层级越深初始化的性能开销越大。Proxy虽然也需要递归处理嵌套对象但它是惰性的——只有在真正访问到某个嵌套对象时才对这个对象做响应式代理初始化性能明显优于Vue 2。第三Proxy还能拦截更多操作比如in操作符、for...in循环、函数调用等等。这些是Object.defineProperty完全做不到的。所以在Vue 3里响应式的边界情况比Vue 2少得多心智负担也更轻。我把这个对比做成了一张表放在答题区特性Vue 2的definePropertyVue 3的Proxy监听新增/删除属性不生效需要额外API原生支持嵌套对象响应式递归初始化性能开销大惰性代理按需处理支持的拦截操作get/set等有限操作get/set/deleteProperty/has等十余种对数组的处理需要重写数组方法原生拦截数组索引和长度变化兼容性IE9不支持IE这道题其实还想考察你是不是愿意花时间去关注框架底层的变化。学Vue不是只学API更要理解它为了解决什么问题而设计。我当时在答案里多写了这句话后来我觉得这可能是加分项。4.3 框架题里的场景设计考察方向这套卷的框架题有个很明显的特色它不会让你单纯背API而是给你一个具体场景问你怎么实现。我记得有一道题是这样的在Vue项目里有一个全局的loading状态要求在任意组件里都能方便地修改它的值同时页面上的loading组件要能响应变化你会用什么方案常规答案是Vuex或者Pinia因为全局状态管理本身就是干这个的。但B卷的高分答案应该再往深走一步为什么要用状态管理库其实核心是为了解决两个问题。第一是把状态从组件里抽离出来形成全局单例组件之间共享数据就不再需要通过props层层传递或者通过事件层层emit。第二是让状态的变化可以追踪Vuex里的mutation和Pinia里的action都做了集中管理数据流的来源和去向是清晰的这在团队协作里特别重要。但更高级的回答是除了状态管理库还可以利用Vue的provide/inject机制来做依赖注入适合跨层级组件共享状态的场景。比如根组件provide一个loading相关的reactive对象后代组件直接inject进来使用这样就绕过了中间层组件必须手动透传props的问题。provide/inject和Vuex的组合使用在真实的业务代码里非常常见——一部分是页面级的局部共享状态用provide/inject就够轻量一部分是应用级的全局状态再做状态管理。这个思路我在后面的开放题里也用到了一部分算是B卷框架题的一个隐藏主线。5. 手写代码题逐题拆解从实现到优化5.1 防抖和节流实现不难难的是边界条件手写防抖和节流基本上是前端笔试的标配了B卷当然没落下。但它的追问方式不一样它给了两个业务场景让你判断分别用防抖还是节流并实现。场景一是搜索框输入关键字实时请求后端接口场景二是页面滚动时记录滚动位置到本地存储。这题我先给的结论是搜索用防抖滚动用节流。防抖的核心思路是频繁触发时只在最后一次触发之后等待一段时间再执行因为用户输入过程中每一次按键都是有效的但真正希望发请求的时刻是用户停顿下来之后节流的核心思路是固定时间内只执行一次因为滚动事件里如果也要等用户完全停下来才记录位置用户中途刷新页面就会丢失最新位置节流保证即使一直在滚动也会每间隔一段时间记录一次。实现时我给的是带立即执行参数的标准版本function debounce(fn, delay, immediate false) { let timer null; return function(...args) { const context this; if (timer) clearTimeout(timer); if (immediate) { const callNow !timer; timer setTimeout(() { timer null; }, delay); if (callNow) fn.apply(context, args); } else { timer setTimeout(() { fn.apply(context, args); timer null; }, delay); } }; }防抖有个很坑的边界条件如果用户一直不停触发呢标准防抖会导致回调永远不执行。所以很多实际项目里会加一个maxWait参数保证在N毫秒内至少执行一次。Vue的源码里debounce实现就考虑了这个点它内部用了一个timerExpired函数递归地设置定时器。我在B卷里额外提了一句这个优化虽然没有展开写但至少让阅卷老师知道我不是只会背书。这题想告诉我们的是手写题不是把代码默写出来就完事关键要证明你能思考到别人容易忽略的边界情况。5.2 深拷贝手写的层次和边界B卷的深拷贝题也有它的要求。它给的题干是请你手写一个深拷贝函数要求能处理数组、对象、日期、正则表达式并且要防止循环引用。基础版本大概是这样function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) { return target; } if (target instanceof Date) { return new Date(target.getTime()); } if (target instanceof RegExp) { return new RegExp(target.source, target.flags); } if (map.has(target)) { return map.get(target); } const cloneTarget Array.isArray(target) ? [] : {}; map.set(target, cloneTarget); for (const key in target) { if (Object.prototype.hasOwnProperty.call(target, key)) { cloneTarget[key] deepClone(target[key], map); } } return cloneTarget; }这里有哪些点是加分项首先是日期和正则的处理很多人的手写深拷贝只考虑对象和数组遇到Date就会退化成普通对象复制出来的值是完全错误的。其次是循环引用如果对象里存在a.self a这样自引用没有WeakMap记录的话会无限递归导致栈溢出。第三遍历对象时要用hasOwnProperty做判断避免把原型链上的属性也复制进来。再往深一点还能考虑Symbol键名、Map和Set等类型但B卷的篇幅和时限决定了这类题的答法不是写得越长越好而是该覆盖的点都覆盖到且没有严重bug。我给这道题的建议是先写主干逻辑基本类型判断、对象数组递归、循环引用处理再补充特殊类型Date、RegExp如果还有精力再扩展Map和Set。这样就算没写全核心分也拿到了。5.3 手写Promise.all考察异步和错误处理的结合B卷有一道手写Promise.all的题目。这个题其实在2020年前后就是前端面试高频题2026年的面试依然是重点只是要求更高了。它考的是你对Promise机制的理解——静态方法怎么和构造函数配合、内部如何同步收集结果、错误如何快速失败。我当时写的版本Promise.myAll function(promises) { return new Promise((resolve, reject) { const results []; let completed 0; const total promises.length; if (total 0) { resolve(results); return; } for (let i 0; i total; i) { Promise.resolve(promises[i]).then(value { results[i] value; completed; if (completed total) { resolve(results); } }).catch(err { reject(err); }); } }); };这个实现有几个值得注意的地方。第一结果数组是通过下标赋值results[i]而不是用push为什么因为Promise的完成顺序是并发的先返回的不一定是第一个元素用下标才能保证结果顺序与传入顺序一致。用push的话结果顺序就会乱掉。第二空数组要直接resolve这个边界很多人会漏。第三任何一个Promise失败就整体reject这是Promise.all的快速失败特性但同时也就意味着其他还在执行的Promise的结果会被丢弃——这就是为什么我在前面的并发上传场景里更倾向于allSettled。这道题的延伸知识点是手写Promise.allSettled和手写Promise.race。B卷虽然只考了all但如果平时能多练几种静态方法的实现考场上万一遇到换皮题就不慌了。6. 编程题思路复盘从组件库设计到大文件上传6.1 开放设计题如果让你设计一个组件库的API你会考虑什么B卷压轴的开放题是如果有足够资源让你从零开始设计一个前端组件库你的API设计思路是什么。这个题没有标准答案我甚至觉得它不完全考技术还在考你有没有做过项目、有没有思考过工程化。我的回答打了一个非常简单的框架稳定、一致、可扩展。稳定指的是API不随意变化一个组件库如果发布后频繁调整props的语义会给使用者带来巨大的维护成本。所以组件props的命名要一致比如visible和open这两种表达方式必须选用一种并贯彻到底。显示和隐藏的回调要么统一叫onClose要么统一叫onCancel不能这个组件用这个、那个组件用那个。一致指的是交互和视觉风格统一按钮的尺寸、输入框的状态、弹窗的层级都应该有统一的设计规范和token体系。可扩展指的是组件要支持自定义插槽或者自定义渲染函数让使用者在不需要改库源码的情况下扩展功能。我额外提到了TypeScript和单元测试在组件库建设里的重要性。TypeScript的泛型机制能让props的约束在编译阶段就被发现单元测试则至少保证Button的点击、禁用、加载等基本交互不会在回归中出现问题。最后我还提了一嘴如果团队工作流允许组件库应该配套提供独立的文档站点和Demo示例一个没有规范文档的组件库在团队里很难被推广。这道题其实就是考察你会不会从0到1搭东西并且考虑到它被其他人使用时的体验。6.2 工程化场景题大文件上传的切片与断点续传B卷里有一道我完全没想到会出现的笔试题——大文件上传。它问前端要上传一个大文件可能是几百MB甚至1GB直接form提交会有什么问题你会怎么设计一个可用的上传方案这明显是酷家乐业务里设计师上传施工图、全景图的真实场景。官方服务条款先不说单从纯前端角度这个题能考察的点非常密集。第一步要答直接整包上传的问题包括请求超时、内存占用过高、失败后只能从头再传、服务端接收超大请求容易受到限制。但这些问题的根源都指向同一个词——一次性传输太大所以拆分的思路是自然的选择。第二步要答把大文件切成固定大小的分片比如每片5MB或10MB切完之后并发上传。这个方案的好处是失败后只需要重传失败的分片不用整个文件重来。关键点在于切片前要为整个文件计算一个唯一的标识可以用文件名的hash加文件大小的组合更稳妥的是借助spark-md5这类库计算文件的hash值作为唯一ID。因为文件内容不变hash就不变下次重新上传时服务端能根据这个ID判断哪些分片已经传过了跳过已传的分片只传缺失的这就是断点续传的核心。第三步要答上传过程中网络断了或者用户手动取消前端怎么恢复。方案是本地记录已上传分片的状态重新唤起上传时先向后端查询该文件的已传分片列表把没传的补上即可。再用Web Worker去处理文件切片和hash计算这种CPU密集任务避免计算hash时页面卡死。我在这里又补充了一个细节并发上限不能太大并发数为3到5比较合适。并发太高会导致浏览器和服务端的连接数压力过大单个分片反而变慢。实测下来5MB的分片大小配合3个并发在绝大多数网络环境里表现稳定。这类题不背答案平时真的写过上传功能的人才能答得这么细。这也是我复盘之后对B卷的整体印象所有开放题都指向一个字——用。6.3 算法题的取舍与做题策略最后简单说说B卷里的算法题。酷家乐的前端卷算法比重不高但有一道我印象很深的字符串处理题。题目要求是给定一个由小写字母和数字组成的字符串按照数字在后、字母在前的规则重新排列并且字母部分保持原有顺序数字部分也保持原有顺序。这题的本质是稳定分区。最容易想到的是写两个循环一个筛字母一个筛数字两个结果拼起来时间复杂度O(n)空间复杂度O(n)。但也可以继续优化到原地操作用双指针做类似快排的partition但要注意稳定这个要求用双指针做原地交换一般会破坏稳定性所以更稳妥的做法是允许用额外空间。做这套卷的建议是不要在算法题上死磕太久。B卷的大头是基础题、框架题和手写题算法题只要能把最朴素的解法写出来、能运行、能讲清楚复杂度基本就可以了。真正拉开分数差距的是前面那些需要结合业务场景分析的题目。7. 这份B卷给准备校招的人的三点启示这套卷子做完复盘完我最想分享的还是那句老话笔试不是考察你会背多少知识点而是考察你在真实场景下能不能用这些知识解决问题。第一点启示要把知识点和业务场景绑定在一起复习。你在准备前端校招时只看防抖节流是什么是不够的得能想到它们在搜索提示、滚动加载这些场景里的位置只看Vue响应式原理的定义也没用得能画出一条数据变化到视图更新的链路图再解释为什么异步更新能带来性能收益。酷家乐B卷所有的题目都在做同一件事——逼你说清楚知识的来源和用途。第二点启示手写代码题不要只背模板。B卷里的深拷贝和Promise.all都是经典题目但如果你只是机械地把代码背下来它后面跟一个场景化的追问你就很难接得住。我建议每刷一个手写题都要问自己三个问题这段代码里哪些边界条件是容易遗漏的这段代码跑在真实业务里的哪个场景如果让我给它加一个新需求我要怎么改把这三个问题回答了这道题才算真正吃透。第三点启示选择对的方向比刷题数量重要。做酷家乐B卷之前先想一想这家公司是做什么的。云设计软件、WebGL渲染、户型图编辑、大量Canvas绘图、图片和材质文件的上传与处理——这些业务决定了它对前端的要求。你在准备它的笔试时与其刷一百道React组件写法不如认真研究Canvas性能优化策略、Promise并发控制、大文件上传这些和业务强相关的技术点。最后再分享一个小技巧笔试的时候遇到开放题别急着落笔先把答题框架在脑子里过一遍。很多开放题都可以用背景—矛盾—方案—关键细节这个结构来组织答案。比如大文件上传题背景是设计师要传大文件直接上传会超时失败矛盾是传输的不稳定性与文件体积大的冲突方案是切片、断点续传、Web Worker结合关键细节是hash标识、并发上限、失败重试。按这个结构答出来的东西得分一定比想到哪写到哪的答案高。这套卷子的复盘就到这里。如果你也在准备类似的前端校招希望这份拆解能帮你少走一些弯路。