每年的秋招都是一场信息战尤其是大厂的笔试不提前摸清套路很容易白给。我参加了贝壳找房2024年秋招前端工程师的第一批笔试今天把整场笔试的完整复盘整理出来从题型分布到考点拆解再到编程题的逐步优化思路还有我踩过的坑一次性说清楚给后面准备贝壳或其他大厂前端笔试的同学一个参考。先说结论贝壳前端的笔试不算偏门整体偏向工程化和基础功底JS核心、浏览器原理、React/Vue框架、算法和场景设计都覆盖了但算法题难度中规中矩没有出现特别离谱的hard题。真正拉开差距的反而是选择题里的细节陷阱以及编程题能否在限定时间内写出健壮的代码。1. 从题型到考点贝壳前端笔试究竟在考什么1.1 试卷结构与时间分配贝壳第一批笔试题型主要分三块单选/多选选择题、简答题、编程题。考试平台用的是牛客网总时长两个小时。选择题大概20道左右覆盖JS基础、CSS、浏览器原理、网络协议、React/Vue框架等简答题2道偏场景设计比如“如何设计一个可复用的前端错误监控模块”编程题2道一道纯算法题、一道偏业务实现的场景题。两个小时看着充裕但实际做起来时间非常紧张。选择题每道平均不能超过2分钟简答题控制在10分钟一道编程题留出充足时间。我个人的时间分配是选择题35分钟简答题25分钟编程题50分钟剩下10分钟检查。实测下来这个节奏还算合理如果在选择题上纠结太久后面编程题会非常被动。还有一点要注意贝壳的笔试会限制跳出页面次数也就是防作弊机制。牛客网后台会记录浏览器切换次数超过一定次数可能会被标记异常。我在考前的习惯是把所有参考材料截图放进本地文件夹避免考试中切出去翻资料。为了一道选择题被判定作弊完全不值得。1.2 考点分布从八股文到工程化实战从选择题的知识点构成来看贝壳的出题逻辑比较清晰。JS基础是绝对的大头this指向、闭包、原型链、事件循环、Promise这些必考CSS里盒模型、BFC、flex布局是常客浏览器部分侧重缓存机制、渲染流程、跨域框架层面React和Vue都会涉及但不是单纯的API背诵更多是考原理层面的理解比如虚拟DOM的diff过程、响应式系统的实现思路。这里有一个值得注意的信号贝壳的笔试明显加重了TypeScript和工程化的比重。选择题里出现了类型推断、泛型约束的题目简答题也暗示了模块化设计。这在往年的贝壳笔试题里不太常见说明团队对候选人的工程素养有了更高要求。如果你还没系统整理过TS的类型体操建议考前至少要把基础类型、接口、泛型、类型守卫这几个核心过一遍。另外关于React和Vue的偏重问题我个人的感受是React占比略高于Vue但两者都会考。原因不难理解贝壳的核心业务包括楼盘详情、经纪人工作台、交易流程等这些系统需要很强的组件抽象能力React的函数式组件加Hooks模式在这些场景里更吃香。但面试笔试毕竟不是定岗位Vue的响应式原理一样会出现在选择题里准备时不要偏科。1.3 贝壳的“场景化出题”逻辑贝壳笔试最明显的特点之一就是喜欢把题目包装到真实业务场景里。比如编程题里会出现“根据筛选条件过滤房源列表”“按区域层级组织楼盘数据”这类题干看似是业务描述本质上仍然是考算法和数据结构。选择里也会有“某个页面白屏你如何排查”这类排查类问题考察的是候选人是否真正处理过线上问题。这其实是一个很重要的信号贝壳前端团队很看重候选人的问题定位能力和业务理解能力。单纯背八股文能过选择题但简答题和编程题里如果写不出有层次的分析思路很难拿高分。2. 选择题高频考点逐项拆解2.1 JS核心this、闭包与事件循环选择题里this指向的变化规律几乎是必考的。常规考点包括普通函数调用、对象方法调用、bind/call/apply显式绑定、箭头函数继承外层this、构造函数里this指向新对象。贝壳的出题方式不会直接让你判断输出而是会在题干里混入多个嵌套关系比如把setTimeout、对象方法、箭头函数组合在一起让你推断最终输出。事件循环也是高频考点。宏任务和微任务的执行顺序看似简单但出题人会在Promise里嵌套setTimeout、在async/await里嵌套同步代码层层叠加后执行顺序很容易绕晕。我建议每做一道事件循环题都在草稿纸上画出任务队列的推入和弹出过程这一步虽然笨但几乎不会出错。还有一点容易被忽视async函数中await后面的代码会被当成微任务但是await右侧的表达式如果是Promise它的执行时机和前一个微任务的关系需要仔细推导。闭包考察的不只是“能不能输出变量”更看重你能否说清楚闭包与内存的关系。选择题里经常出现“以下哪些操作会造成内存泄漏”这类多变体题目涉及定时器未清理、事件监听未移除、闭包引用大对象等。这里有一个习惯值得培养只要在代码里创建了闭包就问一句自己——这个闭包对外部变量的引用是否还应该存在如果不该存在是否已经主动释放2.2 浏览器与网络缓存、渲染、安全HTTP缓存是选择题的常客强缓存和协商缓存的区别基本每年都会考。比较典型的题目是给出一组响应头字段让你判断某个资源在第二次请求时是走本地缓存、发条件请求还是重新下载。这里核心是记住Cache-Control/Expires走强缓存ETag/Last-Modified走协商缓存同时不要忽略Cache-Control的max-age值与no-cache、no-store之间的关系。渲染流程也是容易出题的模块通常会结合CSS和JS的执行顺序来考。比如script标签放在head里会阻塞后续渲染、defer和async的区别、DOMContentLoaded与load事件的触发时机这些点既基础又容易混淆。复习时可以画一条从HTML加载到页面完整渲染的时间线把每个阶段涉及的事件、API、优化手段都标注上比零散记忆更高效。安全方面XSS和CSRF是标准考点。XSS会从“如何防止”的角度出题选项里会混入CSP、HttpOnly、encodeURI、CSRF Token这些手段你要能分辨哪些是防XSS的、哪些是防CSRF的。这道题几乎是白送分但经常有人因为没区分清楚两个概念而做错考前值得专门梳理一遍。2.3 CSS与布局BFC、弹性布局、响应式BFC是前端笔试的“老顽固”贝壳也不例外。常见的创建BFC方式需要熟练记忆overflow不为visible、display为inline-block/flex/grid/table-cell、float不为none、position为absolute/fixed。题目一般会给你一个经典场景——子元素margin溢出父容器问如何解决或者两个相邻元素margin重叠如何避免。只要判断出“需要触发BFC”答案就清晰了。flex布局的考点相对集中主轴方向、主轴对齐justify-content、交叉轴对齐align-items、子项缩放flex-grow/flex-shrink/flex-basis的含义以及flex: 1这个简写展开后的完整值。这里需要特别注意flex: 1是flex: 1 1 0%的简写而不是1 1 auto这个细节曾经多次出现在贝壳和同类大厂的笔试题里。响应式布局通常会结合媒体查询和rem/vw/vh来考。题目会给一个设计稿宽度让你计算某个元素在特定屏幕宽度下应该设置的尺寸。这类题本质上考的是rem换算逻辑和vw的百分比含义。我建议把px转rem的场景题多练几道熟练到不用动脑子就能完成换算。3. 编程题实录与分步演进3.1 shell字符串解析从暴力到简化贝壳这次编程题的第一题是一道字符串处理题。大致场景是把一个含变量占位符的模板字符串解析成实际输出字符串。因为涉及具体业务文案我不能完整复述原题但核心逻辑可以提炼出来。这类题有一个通用的解题框架先识别模板中的占位符规则然后按规则切割字符串最后替换并拼接。我当时的实现思路是function parseTemplate(template, params) { return template.replace(/\{\{\s*([\w.])\s*\}\}/g, (match, key) { const value key.split(.).reduce((obj, k) obj?.[k], params); return value ! undefined value ! null ? value : ; }); }这段代码的正则匹配了{{key}}和{{ key }}两种写法并且支持了a.b.c这种多级路径取值用reduce配合可选链来容错。关键点是占位符缺失时不能报错要返回空字符串因为题目通常会隐藏这个测试用例。从暴力解法角度来说你也可以用indexOf循环查找{{和}}的位置逐段截取替换但代码量和边界处理会明显复杂。这种时候尽量多用正则一个replace函数就足够了。我的经验是字符串处理题先看清楚占位符是否允许嵌套、是否允许转义再决定用正则还是逐字扫描。3.2 树转列表递归与迭代的不同选择第二道编程题是一道数据结构题要求把嵌套的树形结构拍平成一个列表。考的是层级的遍历与记录。原题大约是给出一棵树节点可能有children字段需要输出一个扁平数组同时把层级信息和路径记录保留下来。这里有一个很容易踩的坑题目要求“按深度优先顺序”还是“按输入顺序”会直接影响代码的实现方式。如果是深度优先递归最简单function flattenTree(tree) { const result []; function walk(node, depth) { result.push({ name: node.name, depth, path: node.path }); if (node.children) { node.children.forEach(child walk(child, depth 1)); } } walk(tree, 0); return result; }如果想避免递归爆栈风险可以改用显式栈做迭代遍历代码会稍长但更稳健。大部分情况下递归就够用了因为题目给的数据量不会大到触发栈溢出。但如果题目明确提示“树可能很深”那就要用栈来写。这类树结构在贝壳的业务里也很常见比如行政区划、楼盘户型分类、组织架构都属于典型的层级数据。3.3 业务场景编程题可搜索房源列表的数据处理下午那场笔试不同批次题可能不同的编程题里还有一道偏业务场景的给定一个房源列表需要实现一个筛选和搜索函数支持多条件过滤和关键字查询。这道题考察的是数组的filter、map、reduce等方法的熟练度以及数据不可变性的意识。如果你看到这类题第一步一定是写一个纯函数不要修改原数据。基础版本可以是function filterHouses(houses, { keyword, minPrice, maxPrice, roomType }) { return houses.filter(house { if (keyword !house.title.includes(keyword) !house.address.includes(keyword)) { return false; } if (minPrice ! null house.price minPrice) return false; if (maxPrice ! null house.price maxPrice) return false; if (roomType house.roomType ! roomType) return false; return true; }); }这个实现能过基本用例但要注意如果搜索关键字需要同时匹配标题、地址、小区名不要只写一个includes条件。题目可能要求对搜索词进行分词后多字段匹配如果时间允许可以把多个字段提取成一个可搜索字符串拼接出来再匹配能覆盖更多测试用例。3.4 手写题实现一个简易的 Promise.all除了上面两道有些批次的编程题里会出现手写题或者选择题里有一个“选择实现正确的Promise逻辑”的题目。我遇到的不是完整手写Promise.all而是一道结合场景的选择题但保险起见还是建议大家考前把Promise.all、Promise.race、Promise.resolve的简易实现分别手写一遍。Promise.all的核心逻辑是接收一个Promise数组返回一个新的Promise当全部成功时resolve一个结果数组任何一个失败就立即reject。实现时要注意空数组的处理还要用索引而不是push来保持输出顺序与输入顺序一致function myPromiseAll(promises) { return new Promise((resolve, reject) { const results []; let count 0; if (promises.length 0) { resolve(results); return; } promises.forEach((promise, index) { Promise.resolve(promise).then(value { results[index] value; count; if (count promises.length) resolve(results); }, reject); }); }); }这里的关键点有两个一是Promise.resolve(promise)包裹了一层确保传入的是非Promise值时也能正常运行二是通过count计数来判断是否全部完成而不是直接判断results长度否则数组中的空值会干扰判断结果。4. 贝壳业务场景题的隐藏考点4.1 海量房源列表的渲染优化思路贝壳作为房产交易平台前端绕不开一个核心场景海量数据的列表渲染。一张城市页面可能有成千上万套房源信息直接在React或Vue里把所有节点渲染出来页面必然卡顿。笔试的简答题和场景题里出现这个课题的概率极高。我的答题思路是从“宏观流程”和“微观渲染”两个层面展开。宏观层面先用分页或无限加载控制首屏渲染数量再用虚拟列表保证长列表滚动时只渲染可视区域。微观层面给每一个列表项绑定时确保key值稳定避免整列重新渲染用memo或React.memo包裹列表项组件使未变化的项跳过重新渲染对图片加载使用懒加载配合一个统一的图片占位方案避免数百张图片同时请求。虚拟列表的原理特别适合画图解释。它的思路是基于“可视区域高度 滚动偏移量”计算出当前应该渲染哪几个列表项同时用一块占位元素撑起滚动条总高度。这里有一个容易被忽视的细节如果列表项高度不固定需要提前测量每项高度并缓存否则滚动位置会漂移。贝壳的房源卡片高度接近一致但优惠标签、视频标识可能会撑高卡片实现时建议预留动态高度方案。4.2 房源筛选状态管理不可变数据与URL同步贝壳的找房页面有大量筛选条件比如区域、价格、户型、面积、朝向等。当用户切换条件时需要更新URL参数再请求数据同时还要支持浏览器前进后退。这属于“状态与URL同步”的经典场景笔试简答题里如果问到“如何设计一个房源筛选状态”核心考点就是以下三点。第一推荐把筛选条件封装成一个独立的状态对象用useReducer管理而不是分开写多个useState。因为筛选条件之间存在联动关系比如切换城市后区域选择需要重置用useReducer可以统一处理这类逻辑。第二状态同步到URL时使用history.replaceState或pushState并用URLSearchParams序列化注意不要写入太多无意义参数。第三从URL恢复状态时要考虑参数缺失的默认值以及非法参数值的兜底处理不能让一次手动修改URL直接打崩页面。贝壳这类功能还经常伴随搜索结果的埋点上报所以维护一份可序列化的状态对象非常关键——埋点往往需要一个不含函数的纯数据快照。4.3 前端检测用户“附近房源”定位与异常降级结合贝壳的业务形态“附近房源”功能要求前端获取用户定位信息再将定位坐标传给后端。考点通常不是单纯的API调用而是异常场景的处理。如果用户拒绝授权、浏览器不支持Geolocation、定位超时前端应该如何降级我的思路是先用Geolocation API请求定位设置一个合理的超时时间比如5秒超时后立刻走降级方案比如手动选择城市并通过IP解析粗略城市信息。同时需要区分“定位成功但精度不够”的情况如果取得的coords.accuracy大于一个阈值如500米就用城市级别的搜索兜底而不是直接拿误差过大的坐标去搜“附近”房源。这个思路在回答“如何开发一个前端附近房源功能”这类场景题时非常加分因为考官知道真实业务中定位失败概率不低你能提前写出预案说明你有线上经验。5. 我在笔试中踩过的坑与应变技巧5.1 平台输入输出的适配最容易白给的坑贝壳的笔试在牛客网进行编程题需要自己处理输入输出而且是ACM模式。如果你平时只在LeetCode上刷题习惯了内置的函数参数很容易在牛客网上栽跟头。我第一道题就吃了这个亏读入用readline处理时没考虑到可能存在多行输入需要累积。常见的处理方式是const readline require(readline); const rl readline.createInterface({ input: process.stdin, output: process.stdout }); const lines []; rl.on(line, line { lines.push(line); }); rl.on(close, () { const result solution(lines); console.log(result); });关键是要判断题目输入是“单行连续”还是“多行拼接”如果是多行需要先累积到数组再统一处理而不是每来一行就立刻执行逻辑。另外输出阶段如果要求“多行输出”一定要用console.log多次输出或用\n拼接成单次输出避免最后一行缺失。这种问题浪费的时间最不值因为不是不会做而是平台规则不熟。建议考前专门去牛客网的在线编程环境里模拟两套题熟悉readline和V8引擎下readline的用法这能让你在开考后省下至少10分钟。5.2 时间不够时如何用“部分用例”稳分编程题不是只有满分和零分两种结果。贝壳的牛客网笔试通常是按测试用例比例给分过了多少算多少。这意味着哪怕你的代码只覆盖了最简单的场景也能拿到一部分分数。所以千万不要因为觉得解法不够优就放弃写代码。我的策略是先写一个能过示例用例的线性解法确保基础分拿到再考虑优化。比如树转列表那道题如果递归能过50%用例就先提交再继续优化。注意每道题在提交后可能没有即时反馈所有用例的通过情况你需要在本地用自己能想到的边界测试用例反复验证包括空数组、单个元素、重复元素、超大值。有一个值得一提的细节贝壳的笔试环境在某些批次中不允许你看到错误的具体输入输出只显示“某些测试用例未通过”。这种时候不要慌尽量构造空值、长度为零、单一元素这类极端用例在本地把逻辑跑通再提交。高概率出问题的点通常是正则没有处理空字符串、树节点没有考虑本身为null、递归函数没有终止条件。5.3 简答题的答题框架先结构后细节简答题往往是很多同学失分的重灾区不是因为不会内容而是写得太散。贝壳的简答题是人工阅卷评分老师一天批阅大量试卷如果你的回答没有清晰的小标题和逻辑顺序很容易被低估。我个人的答题模板是“结论先行 分支展开 伪代码兜底”。比如“如何做前端错误监控”先直接说我会从前端错误的采集、上报、聚合、告警四个环节设计。然后逐一展开错误采集分JS运行时错误、资源加载错误、Promise未捕获错误、接口错误四类再给出一段示例代码。最后补充方案上的取舍为什么用img的src上报而不使用fetch上报、日志的采样率如何设计、sourcemap如何安全上传等。这种答题结构即使你对某一环节了解不深整体的专业度也会明显高一个档次。5.4 考后两小时内的复盘优先级笔试结束后尽量趁热打铁做三件事。第一把编程题的完整代码重新整理一遍推敲是否有更优解。如果你还记得题目的大致描述和你的初始代码试着在本地跑一遍并补上所有的边界用例。第二把选择题中不确定的题目记录下来考后根据自己的直觉和关键词重新查资料验证。第三把整场笔试的题目类型和数量记到一个表格里包括选择题多少道、简答题几道、编程题几道这样可以横向对比其他批次的题目难度。我个人的习惯是只记录“不会的题”和“蒙对的题”会的题不再花时间复习。因为笔试的目的是查漏补缺把模糊区域变清晰比重复巩固已知区域更有价值。比如我这次笔试就暴露了一个问题对HTTP缓存的优先级记忆不牢考完之后我专门用思维导图把Cache-Control各指令优先级整理了一遍后续几场笔试遇到类似题再也没有出错。6. 关于贝壳与其他大厂前端的横向比较秋招笔试大多集中在同一时间段很多同学会同时投递贝壳和其他大厂。横向对比下来贝壳的笔试难度在互联网公司中属于中等偏上。相比字节跳动更偏算法、每道题都有一定思维难度的情况贝壳更看重基础面的覆盖和工程化思维的完整性。相比美团偏重考察业务抽象和场景设计贝壳会更直接地把业务场景包装成题目不太绕弯子。从准备策略上说贝壳笔试适合“基础扎实 适度刷题”的路线不需要死磕难题。重点把握住JS核心、浏览器原理、框架使用这几大块再配合一个整洁的答题习惯拿到面试机会的难度不大。但如果基础八股文掌握得模棱两可选择题部分会很吃亏因为贝壳的选择题不设置倒扣分就算蒙也能有25%的正确率多排除一个错误选项正确率就大幅提升。关于面试阶段的准备笔试复盘的意义反而比题目本身更大。贝壳的面试官有很多看过你的笔试记录如果笔试题中的某个点你答得比较仓促面试时很可能会被追问。所以笔试后把每一道题都搞懂而不是只关注分数对后续流程帮助巨大。7. 一点写给2025届及之后的备考建议如果你现在还在准备阶段距离秋招还有几个月我的建议是把时间花在最有杠杆效应的部分。首先是专项基础把知识体系结构化地过一遍推荐用“知识点题目错题笔记”的方式推进而不是零散刷题。其次是熟读面经牛客网、掘金、知乎上每年都有大量秋招笔经面经不要只看题要总结出题思路的变化趋势。最后是保持代码手感每周至少两次完整的笔试模拟严格掐时间模拟完认真复盘。贝壳的笔试每年都会变化但出题逻辑是稳定的基础扎实、工程思维好、碰到业务场景能快速抽象成技术方案。如果你在这些方面有意识地积累拿到面试邀请只是时间问题。最后祝每一位看到这篇文章的读者都能拿到满意的offer。如果这篇文章对你有帮助或者你想了解贝壳前端面试下一轮的具体问题留言区见我会尽量把自己知道的信息和经验整理出来分享给大家。
