如果说秋招笔试是一场没有复习范围的考试那用友集团前端岗的笔试题可以说是“范围很广但方向明确”的典型代表。我2023年秋季参加完这场笔试之后最大的感受是它不像大厂那样死磕算法题也不像小厂那样只问框架API而是把前端基础、工程化、框架原理和B端业务场景揉在一起考题目做起来有一种“这确实是在招能干活的人”的感觉。这篇文章我打算从笔试的前期准备、客观题考点、手写编程题、主观方案题和做题节奏这几个维度展开把我记忆中的题型和踩过的坑全部整理出来。如果你是准备参加用友或者其他ToB软件厂商前端岗秋招的同学这篇文章应该能帮你少走不少弯路。1. 笔试前我做的准备情报收集与考点预判很多人准备笔试习惯直接刷LeetCode或者把Vue文档从头翻到尾但我的经验是先搞清楚这家公司到底是做什么的它的前端团队大概在解决什么问题再去倒推笔试可能考什么这套方法比盲目刷题效率高得多。1.1 用友的业务底色决定了笔试的出题风格用友集团是做企业管理软件起家的核心产品包括ERP、财务系统、人力云、供应链协同这些ToB方向的企业服务。这里有一个很关键的判断ToB软件的前端和ToC产品的前端工作中面对的场景完全不同。ToC产品更看重性能优化、动画体验、跨端适配而ToB产品的前端日常更多在处理复杂表单、数据表格、权限控制、工作流审批、多级菜单这些“企业级中后台”场景。这直接反映在笔试题型分布上。我实际做下来发现客观题里对JavaScript语言本身的考察占比最高其次是CSS布局和浏览器原理框架部分Vue考得比React多用友很多系统是Vue技术栈中间还会穿插几道HTTP和网络安全的题。整体风格偏“基础扎实度”的检验没有出现脑筋急转弯式的前端怪题。1.2 我收集笔试情报的具体渠道和判断方法笔试前一周我做了一件很多人觉得没必要但实际很有效的事把牛客网上往年用友前端笔试题和面经翻了个遍。具体来说分三步第一步搜“用友 前端 笔试”和“用友 秋招 前端”把所有能看到的经验帖都过一遍重点关注帖子里的两个信息——题型结构和出题方向。有帖子提到“手写一个防抖函数”说明他们爱考工具函数有帖子说“考了Vue响应式原理”说明框架原理逃不掉。第二步把搜到的考点全部列出来对照自己的知识盲区。我当时列出的清单大概是事件循环输出顺序、闭包陷阱、原型链题目、数组去重和扁平化、防抖节流、深拷贝、Promise相关的题、虚拟DOM和diff算法、浏览器缓存、跨域解决方案。然后再逐个检查自己哪些题能快速答出来哪些需要临时补。第三步根据用友的产品特征做“业务场景预判”。既然他们做ERP、做B端管理系统那笔试题里大概率会出现菜单权限、数据字典、表单联动这类题目后来证明这个预判非常准后面的主观题就是围绕这类场景出的。1.3 笔试环境与规则预确认这里单独提醒一句笔试前一定要提前确认笔试平台和规则。我当时收到的邮件写的是用牛客网在线笔试需要开摄像头监控。这类线上笔试有几个容易踩的坑技术方面牛客网的系统提交JavaScript代码时不需要自己处理输入输出它会把输入挂在process.argv或者readline上不同题型模板不太一样考前建议先去做几道牛客平台上的“JavaScript输入输出练习”免得开考了还在纠结怎么读数据白白浪费前几分钟。规则方面有些企业笔试禁止跳出页面切屏次数多了会直接警告甚至锁卷。我当时特意把电脑上的弹窗、消息通知全部关掉手机放到离电脑最远的地方。这些细节看起来稀松平常但真的有人在笔试中途被强行交卷那就太冤了。2. 客观题考点全景从JS基础到框架原理用友笔试的客观题部分大概有30道左右题型以单选、多选和判断为主。考点覆盖面比较广但整体没有跳出前端核心知识体系。我按实际考试中出现的频率和权重把它们分成四个梯队逐个说清楚。2.1 第一梯队JavaScript语言基础这一块是绝对重头戏占比接近三分之一。考的方式不是让你背概念而是给你一段代码让你输出执行结果。比如闭包和循环结合、this指向问题、原型链查找过程这些几乎必考。举个典型的例子for循环中var声明变量和setTimeout组合输出什么这个题目本质考的是闭包捕获和变量作用域。用var声明的循环变量i是函数作用域循环结束后i已经变成了最终值所以所有setTimeout回调打印的都是同一个值改成let声明后每次循环都会生成一个新的绑定回调就能打印出正确的递增序列。再比如this指向的经典场景普通函数调用、对象方法调用、构造函数调用、箭头函数定义位置的this继承这些都要能快速判断。我一个很深的体会是这类题靠死记结论是没有用的必须理解JavaScript执行上下文和词法作用域的关系才能真正应对各种变形题。2.2 第二梯队浏览器原理和网络基础浏览器渲染过程、重排和重绘、事件循环、垃圾回收机制这些是第二梯队的高频考点。事件循环的题目尤其常见经常结合Promise和async/await出输出顺序题。我记得有一道题大概是这样的console.log(start); setTimeout(() { console.log(timeout); }, 0); Promise.resolve().then(() { console.log(promise1); }).then(() { console.log(promise2); }); console.log(end);这个输出顺序是start、end、promise1、promise2、timeout。核心逻辑是同步代码先执行完毕然后微任务队列Promise的回调清空再执行宏任务setTimeout回调。我当时笔试时把微任务和宏任务的优先级写反了后来复盘发现问题出在“对微任务队列的刷新时机理解不够深入”——它不是每一轮宏任务后刷新一次而是当调用栈清空后会一次性把所有微任务都执行完直到队列为空才会继续取下一个宏任务。网络部分HTTP状态码含义、浏览器缓存的强缓存和协商缓存、HTTPS握手过程、跨域方案JSONP、CORS、代理都属于基础送分题准备到位了就没什么问题。但有一类变形题需要注意给你一个请求的响应头和请求头让你判断命中强缓存还是协商缓存以及下次请求会发什么字段、收到什么字段。这个光记住“强缓存不请求服务器协商缓存要发请求”是不够的还得知道Cache-Control的max-age、no-cache、no-store含义以及ETag和Last-Modified的配合关系。2.3 第三梯队CSS布局与视觉细节用友的笔试对CSS的考察不深但覆盖面很实在盒模型、flex布局、grid布局、定位、BFC、垂直居中方案、移动端适配这些基础概念至少要能说得清楚。flex布局几乎每年都考几个核心问题要滚瓜烂熟flex-direction控制主轴方向、justify-content控制主轴对齐、align-items控制交叉轴对齐、flex-grow和flex-shrink控制子项伸缩比例。有一道题我记得挺有意思一个容器设置display:flex三个子项分别设置flex:1、flex:2、flex:3问三个子项在主轴上的宽度比例。答案就是1:2:3因为flex属性是flex-grow、flex-shrink、flex-basis的组合简写当容器宽度足够且flex-basis取默认值auto时剩余空间会按照grow比例分配。BFC这道题在笔试里出现得也很多。考题通常问的是“如何触发BFC”答案有float不为none、position为absolute或fixed、overflow不为visible、display为inline-block或flow-root、display为flex或grid的容器。更关键的考法是问你BFC解决了什么问题阻止外边距折叠、防止浮动元素溢出、阻止元素被浮动元素覆盖。这些不只是面试八股实际做B端页面布局时真的天天碰到。2.4 第四梯队框架原理与工程化框架部分Vue的内容明显多于React这和用友的技术栈有关。考察点集中在Vue2的响应式原理、Vue3的Proxy响应式、生命周期顺序、组件通信方式、v-if和v-show的区别、computed和watch的区别、Vuex状态管理等。有一道题我印象很深问Vue2中数组的索引赋值能不能触发视图更新。不能因为Object.defineProperty只能拦截对象的属性访问和设置无法拦截数组索引的赋值操作。Vue2是通过重写数组的push、pop、shift、unshift、splice、sort、reverse这些方法来实现数组变更的响应。Vue3用Proxy之后数组索引赋值可以正常触发更新因为Proxy代理的是整个数组对象任何属性的读写都会被捕获。工程化方向考了模块化CommonJS和ES Module的区别、webpack的loader和plugin的区别、打包优化手段。这些题不算难但需要平时工程实践中有积累不能纯背概念。比如问你webpack的loader和plugin有什么区别光答“loader处理文件转换plugin做构建生命周期钩子”只能及格能说出“loader的执行顺序是从右到左、从下到上”“plugin通过tapable的hooks机制注册回调”就更显水平。如果客观题部分能拿到70%以上的正确率后面的手写题压力就会小很多。这部分我的建议是不要只记答案每个考点都要能用自己的话解释清楚为什么最好能随手写一个最小可复现的代码片段去验证。3. 手写编程题从工具函数到并发控制的实战拆解用友笔试的手写编程题大概有3道整体难度中等偏上没有特别变态的算法题但也不是简单到直接送分。题型偏“工作中真正会用到”的工具函数以及一些贴近实际业务场景的逻辑题。我做题时最大的感受是及格容易满分难关键看你对边界条件的处理是否足够严谨。3.1 高频工具函数题防抖、节流、深拷贝防抖和节流这两个函数几乎是前端笔试手写题的“保留曲目”用友考到了其中一个实现一个防抖函数。我当时写的大致版本是function debounce(fn, delay) { let timer null; return function (...args) { if (timer) clearTimeout(timer); timer setTimeout(() { fn.apply(this, args); }, delay); }; }这个版本能拿到基础分但要注意几个细节第一返回的函数内部this要透传给原函数所以用了fn.apply(this, args)第二要支持参数透传所以用了rest参数第三如果要求立即执行版本需要在触发时额外判断timer是否为空。如果笔试中还有余力可以再补充一个带取消功能的版本代码长一点但能体现思考深度。深拷贝是另一道高频手写题而且用友笔试里出现的概率很高。我当时的做法是递归实现但对数组、日期、正则这些特殊类型单独处理function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) return target; if (target instanceof Date) return new Date(target); if (target instanceof RegExp) return new RegExp(target.source, target.flags); const existing map.get(target); if (existing) return existing; const clone Array.isArray(target) ? [] : {}; map.set(target, clone); for (const key of Object.keys(target)) { clone[key] deepClone(target[key], map); } return clone; }这段代码的关键是用WeakMap解决循环引用问题。如果不加这个处理遇到对象属性形成环的场景会直接爆栈。我当时在笔试时把WeakMap这个关键点写上了这部分得分应该不错。另外还需要提到的是Symbol作为属性名时Object.keys拿不到需要用Reflect.ownKeys或者Object.getOwnPropertySymbols但实际笔试题如果没明确要求能做到上面这个程度已经够用了。3.2 业务场景题并发请求控制这道题当时让我有点意外因为它的味道非常“业务化”题目大概是这样有10个异步请求要求限制并发数为3同一时间最多只有3个请求在执行所有请求完成后返回所有结果。这道题本质上考察的是异步流程控制和队列思想。我的解题思路是维护一个任务队列同时启动了3个“常驻”的执行器每个执行器每次从队列头部取一个任务执行执行完继续取下一个直到队列清空。async function concurrentFetch(tasks, limit) { const results []; let index 0; async function worker() { while (index tasks.length) { const current index; try { results[current] await tasks[current](); } catch (e) { results[current] e; } } } const workers Array.from({ length: limit }, () worker()); await Promise.all(workers); return results; }这道题的核心是不要让每个任务自己调度自己而是让固定数量的worker循环去队列里取任务。这样无论任务数量多大同时执行的任务数永远不超过limit。而且这里用while循环而不是递归不会产生深层调用栈的问题。现场写的时候我一开始想的是用递归实现每个任务的调度结果写一半发现逻辑绕进去了后来改成worker模式代码一下就清晰了。这就是笔试现场很可能发生的状况——第一版不是最优解快速调整思路比死磕更重要。3.3 算法基础题LRU缓存LRU缓存淘汰算法是后端面试常客但前端笔试现在也越来越爱考。用友笔试中我遇到了一道相关题目要求手写一个LRU缓存类支持get和put两个方法容量固定超出容量时淘汰最久未使用的key。我当时用的方案是Map 最近访问置后的技巧因为Map在JavaScript中会维护键值对的插入顺序所以天然适合做LRUclass LRUCache { constructor(capacity) { this.capacity capacity; this.map new Map(); } get(key) { if (!this.map.has(key)) return -1; const value this.map.get(key); this.map.delete(key); this.map.set(key, value); return value; } put(key, value) { if (this.map.has(key)) { this.map.delete(key); } this.map.set(key, value); if (this.map.size this.capacity) { const oldestKey this.map.keys().next().value; this.map.delete(oldestKey); } } }get的时候先删掉再重新set这样这个key就变成了“最新插入”排到了Map的末尾。Map的keys()返回迭代器.next().value就能拿到“最久未使用”的第一个key。这个方案比用双向链表哈希表简单太多而且JavaScript里Map的复杂度也是O(1)完全够用。这类题平时要多写几遍不能只看不练。笔试现场手写代码如果你对这个算法的套路不熟练光是把插入顺序和删除顺序理清楚就得花不少时间。3.4 手写题的四个得分要点手写题批卷的时候考官通常会按点给分。我根据自己的笔试经验和后来帮朋友复盘笔试的经验总结出四个决定能否拿高分的点第一变量命名要清晰。不要用a、b、c这种无意义的名字用fn、delay、timer、tasks、results这些能“自解释”的命名阅卷体验会好很多。第二边界条件要主动覆盖。防抖函数的第一次触发要不要立即执行深拷贝遇到循环引用会不会爆栈并发控制中某个任务抛出异常会不会导致整体崩溃这些问题哪怕题目没明确要求你也应该主动处理并且可以在代码注释里标注“此处处理xx边界情况”让阅卷人看到你的思考。第三主流程正确优先优化其次。如果时间不够先把主流程跑通再去补边界。不要一上来就在细节里绕导致整道题都写不完。第四写完回头读一遍自己的代码。很多人写完就提交其实手写代码时很容易出现笔误比如把delete写成了remove、把map.has写成了map.get回头整体读一遍能抓住很多低级错误。4. 主观题与综合题B端场景下的前端方案设计笔试的最后一部分通常是主观方案题用友这块的出题风格很有代表性几乎就是围绕它们日常业务里的前端场景来设计的。题目没有标准答案考察的是你对真实场景的理解深度和方案设计能力这恰恰是很多只刷题不实践的同学容易丢分的地方。4.1 权限管理系统的前端实现方案这道题我印象特别深刻题目大致是公司需要在管理后台中实现基于角色的菜单权限和按钮权限控制请设计前端实现方案描述角色、权限、菜单路由、页面按钮之间的关联关系。这类题目的核心不在于你写了多少代码而在于你能不能用清晰的思路把权限模型讲明白。我的作答思路分了三层第一层是数据模型设计。用户属于角色角色拥有权限标识集合每个菜单路由关联一个或多个权限标识每个页面按钮也关联一个权限标识。这样当用户登录后后端返回该用户拥有的所有权限标识数组前端只需要做“按权限标识过滤”这一个动作。第二层是路由级权限控制。动态路由的场景下路由不能一次性全量注册而应该根据当前用户的权限标识集合动态筛选出可访问的路由再注册。配合路由守卫在每次跳转前检查目标路由所需的权限标识是否存在于当前用户权限集合里不存在就重定向到404或无权限页。第三层是按钮级权限控制。我当时的方案是封装一个指令比如v-permission页面渲染按钮时检查当前用户是否拥有该按钮绑定的权限标识没有就从DOM中移除。也可以用自定义组件包裹按钮通过props传入所需权限标识内部判断有无权限决定是否渲染。这道题能拿高分的另一个加分项是提到“权限标识的命名规范”。比如用模块名:动作名的格式user:create, order:delete避免权限标识重复同时方便后端做统一管理。这个细节不是题目直接问的但能体现你真在项目里搞过权限系统而不是只会背概念。4.2 大数据量表格性能优化方案另一道主观题是关于B端系统表格性能的一个表格需要渲染上万条数据页面出现卡顿请给出优化方案。这道题考察的是你对前端渲染瓶颈的理解。我当时从渲染、加载、交互三个层面分别说渲染层面优先考虑虚拟滚动/虚拟列表。只渲染可视区域内的行窗口滚动时动态更新渲染内容让DOM节点数量始终保持在一个很小的水平。桌面端浏览器在处理几百个DOM节点时都很流畅但一次性插入上万个节点必然卡顿虚拟滚动的本质就是把“渲染所有数据”变成“只渲染看得见的数据”。加载层面如果能分页就别一下加载一万条。服务端分页、前端分页、无限滚动按实际情况选择。如果数据量实在太大也可以考虑后端做汇总统计前端只展示结果。交互层面开启content-visibility: auto这个CSS属性可以让浏览器跳过屏幕外元素的渲染工作配合contain-intrinsic-size预估元素尺寸是一个轻量级的优化手段。表格列过多时开启列虚拟化、懒加载非首屏列的数据。行内编辑场景避免每次输入都触发整个表格重渲染组件粒度要拆到单行或者单单元格。还有一点我认为很加分提到“区分真实场景需求”。如果只是展示型表格用户不需要同时操作所有行虚拟滚动足够如果表格行内包含复杂表单组件每个单元格都是完整表单状态那表格本身的设计可能就有问题应该改为“行编辑/弹窗编辑”模式。这种“能结合场景做取舍”的表达比堆方案更能打动阅卷人。4.3 复杂表单联动与校验的逻辑设计还有一道让我印象深刻的主观题问的是B端系统里有一种常见场景表单字段之间相互联动比如选择“发票类型”后“发票抬头”和“税号”字段的显隐、必填状态、可选项都会发生改变请设计一个前端表单联动方案。我答题时首先点出了这个问题的核心难点如果像传统方式一样把联动逻辑分散写在各个字段的change事件里字段一多代码就会变成一团乱麻——a变了要改bb变了要改c和dc变了又回头改a整个逻辑无法追踪。我的方案是用“数据驱动配置化”的思路把字段状态提升到一个统一的状态容器中每个字段的可见性、禁用状态、必填状态、选项列表都根据一个总体的“表单上下文”计算得出。当任何一个字段值变化时重新计算表单上下文再驱动所有字段更新状态。伪代码思路是const fieldConfigs [ { key: invoiceType, label: 发票类型 }, { key: invoiceTitle, label: 发票抬头 }, { key: taxId, label: 税号 }, ]; function computeFieldState(context) { const state {}; const isCompanyInvoice context.invoiceType company; state.invoiceTitle { visible: isCompanyInvoice, required: isCompanyInvoice }; state.taxId { visible: isCompanyInvoice, required: isCompanyInvoice }; return state; }这样做最大的好处是字段一多逻辑依然清晰新增联动规则只需要在computeFieldState里加不需要在上百个事件回调里找来找去。这个方案在Vue和React里都能实现只是实现细节略有不同——Vue可以用computed或者watchEffect来监听表单上下文的变化React则结合useMemo或者状态管理库。4.4 主观题的答题策略主观题不像客观题有标准答案但阅卷人心里有“大概好”和“大概不行”的区别。我自己的体会是答主观题要抓住三件事第一结构化表达优先。先给结论或者总体思路再分层展开每层都用小标题或序号标出来。不要写成一整段话绕来绕去阅卷人看得很累。第二既能说方案也能说理由。给出方案后一定要补一句“为什么”。比如菜单权限用动态路由方案因为静态路由在前端不管用户能不能访问都注册了存在被手动修改路由跳过的风险动态路由配合守卫才能做到前端层面的硬隔离。第三诚实说明取舍。如果某个方案你知道更好的替代品但没实际用过就说“我了解过的另一种方案是xx但还没有在项目中实践过”。不要硬编业内人一眼就能看出你有没有真做过。5. 做题节奏与踩坑复盘时间分配和现场策略笔试当天的实际做题节奏直接决定了你最终能把掌握的能力发挥出几成。用友这场笔试总时长大概在90分钟左右题量不算小如果没有时间分配策略很容易出现后面的大题没时间好好写的局面。5.1 我实际采用的时间分配方案我给自己定的策略是客观题控制在40到45分钟内完成剩下45到50分钟全部留给手写题和主观题。客观题里遇到卡壳超过1分钟的题目先标记跳过去等把会做的全部做完再回头啃。坚决不在单选题上耗5分钟因为后面一道手写题20分一道选择题也就2分性价比完全不在一个量级。有些客观题你纠结很久也未必能选对而那些分攒起来却能决定你能否进入下一轮筛选。手写题三道的分配大致是10分钟、12分钟、15分钟留下十分钟给主观题。当然每个人基础不一样这个比例仅供参考核心原则是主观题绝对不能空着哪怕写不出完整代码也要把思路、结构、关键函数名写出来。B端方案设计题的采分点很多都在思路上代码权重反而不高。5.2 我踩过的坑和复盘第一个坑是客观题里关于事件循环那道题。我因为对微任务和宏任务的刷新机制理解得不够透彻把Promise.resolve().then回调的顺序排错了。复盘才发现我在准备阶段只记住了“微任务先于宏任务”这个结论但没理解“每执行一个宏任务后要清空整个微任务队列”这个完整语义。这个教训让我后面复习事件循环时不再背结论而是自己手动画执行过程图。第二个坑是并发控制那道题。一开始我陷入了递归调用的陷阱代码写了一多半自己读了一遍发现逻辑有问题时间又过去了五分钟赶紧擦掉重写worker版本。这个教训是笔试现场如果一种思路写起来越来越绕大概率不是你的代码能力不行而是思路本身不够顺。果断换思路不要将错就错。第三个坑是环境调试。做手写题时一开始我没注意牛客平台提供的代码模板习惯性地把自己脑子里默认的函数签名写了上去结果测试用例过不了。后来发现平台模板已经给了一个空函数只需要在函数体里填充。这个细节提醒我拿到题目先花30秒看清楚模板和函数签名不要一上来就埋头写。5.3 现场策略清单笔试当天有用的三个动作开考前先快速浏览一遍所有题目心里对“哪道题容易拿分、哪道题难啃”有数。先快速拿分再处理难题。手写题的代码虽然不会真正编译运行具体看平台规则但自己写完一定要在脑子里“跑”一遍尤其是for循环、while循环、递归这类容易出错的逻辑。如果主观题时间不够了写一个精简版但完整的大纲至少把回答的层次和二三级要点写出来好过交白卷。6. 笔试之后接着补的功课这套考点背后的学习主线笔试结束后我没有立刻放松而是认真复盘了这次笔试涉及的考点发现一个规律用友笔试的知识点本质上就是一套比较完整的前端工程师能力模型。如果你把这套考点吃透了不仅是用友大部分ToB软件公司的前端笔试你都有把握。这个能力模型大致是JavaScript语言底层机制做根基浏览器和网络原理做支撑主流框架的原理和工程化能力做扩展最后落到复杂业务场景的设计能力上。JavaScript底层机制这块闭包、原型链、this、事件循环、异步编程是其他所有上层知识的地基。地基不稳后面全都不牢。我当时的复习方式是每学一个机制就在浏览器控制台里写一个最小例子去验证然后给自己出题把输出结果写下来再去对照工具验证。这个习惯能显著加速“死记结论”到“真正理解”的转化。浏览器原理这块渲染机制、缓存、事件机制、Web安全XSS、CSRF看起来是独立的知识点但它们共同回答一个问题前端代码在浏览器里到底是怎么跑起来的。理解了这个“底层工作流”很多笔试题目都可以推导出来而不是靠背。框架部分不要只背生命周期和API。Vue的响应式原理、虚拟DOM和diff算法、组件通信方案这些才是面试官真正想看到的“理解深度”。如果你时间充裕可以自己尝试写一个极简版的双向绑定或者虚拟DOM哪怕是玩具级别的实现也能帮你把原理理解带上一个台阶。工程化方面webpack、vite、npm包管理、代码规范、Git工作流这些考查的不是你会不会用而是你理解不理解“为什么要这么设计”。比如loader为什么从右往左执行、plugin和loader为什么分开设计理解了设计动机记起来也顺利得多。最后是B端业务场景的积累。这类能力短期刷不出来主要是靠日常项目经验。但如果你还在校没有太多真实项目可以通过读一些优秀的开源中后台项目源码、自己写一个带权限控制的简单管理系统来积累。关键是把权限控制、动态路由、表单联动、大数据表格优化这些常见场景都亲身走一遍哪怕只是demo级别笔试时都能说出“我做过”而不是“我听说过”。我在准备用友笔试和复盘的过程中最深的一个体会是前端笔试没有捷径但也没有玄学。它的考察逻辑是稳定的只要你按照“底层机制—运行原理—框架实践—业务方案”这条主线扎实梳理把每个考点都做到“能解释、能推导、能写代码”拿到的结果大概率不会差。希望这篇复盘能帮你在自己的笔试路上少踩几个坑把时间花在刀刃上。