我印象里美团春招笔试的出题风格一直很实在——不搞花哨的脑筋急转弯更看重基础扎实程度和工程思维。2024年春招前端移动端第一批笔试整体考察重心依然围绕移动端适配、性能优化、框架原理和工程化这几个方向展开。这篇文章我尽量把当时考完复盘的重点、题目背后想考察的能力模型以及备考过程中真正有用的资料和工具都整理出来。不管你是准备参加下一批笔试还是单纯想检验一下自己的前端基础这份复盘应该都能给你一些具体可参考的东西。1. 这场笔试在考什么从岗位画像反推考察范围1.1 美团前端移动端的岗位定位在聊题型之前我觉得有必要先搞清楚一件事美团招前端移动端方向的人到底是让候选人去做什么。这个岗位不像纯Web端那样只关注页面展示移动端的核心痛点是性能、流量、兼容性和体验。你在手机上打开美团App首页、订单列表、餐饮团购详情页、地图配送轨迹这些场景对前端的要求就是极致的渲染效率、弱网环境下的稳定性、以及不同终端下的统一体验。从笔试题目也能看出来美团在筛选的过程中并不会只考会不会写代码这种基础能力而是更关注候选人有没有移动端思维。比如同样一个页面渲染问题在PC端可能就是FPS掉一点但在移动端就是卡顿、白屏、用户流失。笔试里安排移动端专项题本质就是测试你是否具备这种场景敏感度。我在做题的时候有一个很直观的感受它的题目描述里经常出现低端机弱网内存占用这类具体业务语境的词汇。这说明出题人很在意候选人对真实设备环境的理解而不是仅仅停留在浏览器上能跑就行的层面。1.2 笔试四类题型的整体结构美团2024春招前端移动端第一批笔试的题型分布我大概归成四类。第一类是计算机基础选择题涵盖网络协议、数据结构、操作系统基础这一类很多同学容易掉以轻心觉得前端不需要看但实际上移动端极其依赖HTTP/HTTPS、TCP连接复用、缓存体系这些东西。第二类是前端基础与JavaScript考察主要是作用域、闭包、原型链、事件循环、Promise、ES6语法偶尔会考到CSS布局和移动端适配。第三类是框架与工程化题React/Vue原理、组件通信、状态管理、Webpack/Vite配置、模块化规范。第四类是编程题有的是纯算法有的是模拟实现某个前端功能比如实现一个带防抖的搜索框、实现一个移动端手势组件、用代码模拟并发控制等。这里要提醒一句不同批次的笔试可能存在难度浮动但整体的考察框架基本稳定。你复习的时候不需要去猜它会出什么偏题怪题而是要把这四块基础打牢。1.3 从热搜词看今年的命题风向我考前习惯做一件事把最近两三个月前端相关的热搜词、技术社区的热门讨论过一遍借此判断行业的关注重心。2024年春招前后移动端性能优化vConsole移动端调试ECharts折线图移动端tooltip显示前端Worker上传大文件微前端这些话题的热度都很高而这些词恰好和笔试考点高度重合。这不是巧合而是行业需求在倒逼候选人能力模型升级。移动端性能优化说明业务方越来越关注真实用户体验vConsole说明移动端调试本身就是日常工作的高频场景Worker上传大文件说明前端工程化已经从简单的页面开发进化到处理复杂业务逻辑的阶段微前端说明很多中大型团队在解决多团队协作、存量系统迁移的问题。笔试紧跟这些方向说明美团希望招到的人不是只会写页面而是能解决真实工程问题的人。我也建议正在准备笔试的同学不要只看面试题汇总最好花一点时间看看社区里正在讨论什么。很多笔试题目其实就是把一个热门的技术痛点改写成了一道考察题。2. 移动端专项从浏览器适配到调试工具的实战考点2.1 移动端适配方案笔试中最容易出错的送分题移动端适配在美团笔试里几乎是必考内容但准确率反而不高。核心考点有三个viewport配置、rem/vw适配方案、以及高清屏下的1px问题。Viewport的常规配置是meta nameviewport contentwidthdevice-width, initial-scale1.0, maximum-scale1.0, user-scalableno但要真正理解每个字段的作用不能只背标签。笔试有时候会问如果去掉initial-scale1.0会出现什么问题实际上是考察你是否知道移动端浏览器默认的布局视口宽度通常大于设备宽度如果不显式设置页面会出现横向滚动或整体缩小。Rem适配的核心公式是根字体大小 设备宽度 / 设计稿宽度 * 基准字体大小。很多候选人能背出这个公式但笔试会换一种方式问比如设计稿宽度750px某个元素宽度在iPhone 6/7/8375px上应该设置为多少rem这时候就需要根据公式反推。我记得这道题的陷阱在于iPhone 6/7/8的设备像素比是2CSS像素宽度是375px如果你直接用375除以750得0.5再乘以基准值得到的结果其实是正确的但如果你用物理像素750去除就会得到1倍单位换算直接翻车。1px问题的本质是devicePixelRatio导致CSS 1px在物理屏幕上实际显示为2px或3px视觉上偏粗。主流方案有transform: scale(0.5)、border-image、以及通过viewport的initial-scale配合rem实现全局缩放。笔试更多是考原理和方案对比你需要说清楚每种方案的优缺点。我的建议是把viewport rem这个组合方案理解透彻因为它也是后面做移动端页面性能优化时经常用到的基础能力。2.2 vConsole移动端页面调试的物理外挂移动端页面的调试一直是个痛点。PC端你可以直接打开DevTools但在手机上真机访问页面时压根没有控制台可用网络请求、console日志、LocalStorage这些一概看不见。笔试里会考察开发调试工具的使用这既是对工作习惯的考察也是对你是否了解移动端开发完整流程的考察。vConsole是一个移动端调试面板工具它做的事情很简单在页面里注入一个类似DevTools的面板让你在移动端浏览器里直接查看Console日志、Network请求、Cookie/LocalStorage、系统信息等。笔试中可能出现的考法是让你实现在任意移动端页面中通过脚本插入vConsole。最直接的方式是通过url参数动态控制只有带debug参数时才加载脚本避免线上环境误开调试面板(function () { var params new URLSearchParams(location.search); if (params.has(debug)) { var script document.createElement(script); script.src https://cdn.jsdelivr.net/npm/vconsole/dist/vconsole.min.js; script.onload function () { // 创建实例并挂到全局 window.vConsole new window.VConsole(); }; document.head.appendChild(script); } })();这段代码在真实工作里可以直接用笔试里你如果能够写出来并且补充说明生产环境需要加白名单动态加载避免影响首屏性能就比单纯回答用vConsole要加分很多。还有一个小技巧是配合构建工具使用开发环境自动注入、生产环境通过url参数开启。我当时笔试时还补充了一种方式localStorage里存一个开关标记页面加载后主动读取并决定是否注入vConsole。这种方式适合部分内部测试包线上用户也不会受到影响。整体思路就是让调试工具的加载具备可控性而不是每次都要手动改代码重新发布。2.3 ECharts折线图移动端tooltip显示不全的经典场景ECharts在移动端的使用率极高美团这类业务大量依赖数据可视化比如订单趋势、配送时长分布、用户增长曲线。笔试里关于ECharts的题目大多不是让你背API而是考察你在移动端场景下的实际处理能力这中间最经典的一个问题就是折线图渲染完成后如何让最后一个点的tooltip自动显示出来。为什么这个问题值得单独拎出来考因为移动端屏幕窄用户手指点击最后一个数据点时容易误触、点不中如果产品上需要突出最新值比如展示最新一天的用户数这个需求就会落到前端头上。解法有两种思路。第一种是调用dispatchAction触发高亮和tooltipchart.setOption(option); // 等渲染完成后再触发 chart.on(finished, function () { var dataLength option.series[0].data.length; chart.dispatchAction({ type: showTip, seriesIndex: 0, dataIndex: dataLength - 1 }); });这里有一个关键showTip的触发必须在finished事件之后否则图表还没渲染完坐标轴的index对不上。如果你在setOption之后立即dispatchAction大概率拿到的是undefined。第二种方式是使用highlight但highlight只能高亮图形不能显示tooltip浮层要配合showTip一起用。笔试里如果遇到这个题建议把dispatchAction的showTip和highlight两个动作都写上同时注意seriesIndex是数组下标如果图里有多条折线需要明确指定你要展示的是哪一条。还有一个细节是移动端手指点击tooltip后浮层不应该超出屏幕边缘。你可以给tooltip配置confine: true这样ECharts会自动把浮层限制在canvas容器内避免边缘遮挡问题。这个配置项在PC端不明显但在移动端非常实用我在实际需求里用过很多次。2.4 移动端常见的兼容性考察点touch事件、300ms延迟和滚动优化移动端笔试很少会直接问你怎么做移动端兼容它会把兼容问题拆成一个个小的选择题或简答题。Touch事件是高频点。移动端没有mouse事件那套语义click在移动端会有300ms左右的延迟虽然现代浏览器通过meta nameviewport contentwidthdevice-width已经去掉了这个延迟但在老版本WebView里依然存在。你需要知道touchstart、touchmove、touchend这套事件体系和click的区别以及在什么场景下需要手动处理那个300ms延迟。滚动优化也是一个隐含考点。移动端滚动卡顿的本质是主线程渲染和滚动线程的协调问题一道经典的考察方式是让你优化一个长列表滚动常规答案包括使用transform: translateZ(0)开启GPU合成层给滚动容器加-webkit-overflow-scrolling: touchiOS对非可视区域的DOM做懒渲染或回收用will-change: transform提前告知浏览器这些方案里-webkit-overflow-scrolling: touch和will-change属于性能优化的工具手段笔试更想看到的是你理解为什么需要避免滚动时频繁触发重排和重绘。如果你回答的时候能提到合成器线程只处理合成层的位图变换不触发layout和paint那就说明你是真的理解了移动端渲染流程。3. 性能优化与工程化笔试里的重头戏与加分项3.1 移动端性能优化的指标到底看什么性能优化在美团的笔试里属于必考模块。但它在选择题里考得不多更多的会在编程题和简答题里出现比如线上页面打开速度变慢请给出排查思路、如何优化首屏白屏时间这类问题。移动端性能优化常用的指标有FCPFirst Contentful Paint、LCPLargest Contentful Paint、CLSCumulative Layout Shift、INPInteraction to Next Paint和TBTTotal Blocking Time。笔试里直接考缩写定义的概率不大但会考你如果用Performance面板定位卡顿你应该看哪些项。比如白屏问题你需要看请求队列是不是有长任务卡住了首屏资源如果FCP正常但LCP很慢可能是首屏大图加载慢或者图片被JS延迟加载策略拖累了。我整理一个表格方便大家对照指标和典型的优化动作指标关注内容常见优化手段FCP首个内容绘制时间内联关键CSS、减少render-blocking资源LCP最大内容绘制时间图片懒加载策略调整、优化CDN回源、使用preloadCLS页面布局偏移给图片和广告位预留占位空间INP交互响应延迟减少主线程长任务、拆分同步计算TBT主线程阻塞时间Web Worker分担计算、懒加载非核心JSTTI可交互时间减少DOM节点数量、优化JS执行时间笔试里如果你能把这些指标的关联性讲清楚会显得很有经验。比如LCP和CLS的关系如果你没有给首屏图片预留高度占位图片加载完成后页面内容会向下跳动导致CLS飙升用户的视觉感受是图片突然挤开文字很影响体验。这种联系是刷题刷不出来的需要在真实页面里做过性能优化才能写出来。3.2 大文件上传Worker在其中的实际价值大文件上传是美团这类有内容发布场景的业务里很常见的需求。笔试里考察Web Worker的动机并不单纯是问说说Worker用过没有而是看你在处理CPU密集任务时有没有工程化思维。大文件上传的经典方案是分片上传。前端把文件切成若干个分片每片独立计算MD5然后顺序或并发上传后端收到全部片后合并。分片能解决大文件失败重传整个文件的问题但分片本身有个隐藏问题文件分片后的MD5计算是CPU密集型运算如果文件有几百MB甚至1GB在前端主线程算MD5会导致页面卡死用户点哪里都没反应。正确的思路是把分片和MD5计算都放到Worker线程中执行主线程只负责收发消息和更新进度条。核心代码如下// main.js const worker new Worker(/upload-worker.js); worker.postMessage({ file, chunkSize: 5 * 1024 * 1024 }); worker.onmessage (e) { if (e.data.type hashProgress) { updateProgress(e.data.percent); } if (e.data.type chunks) { uploadChunks(e.data.chunks); } };在Worker里你需要读取文件内容浏览器环境没法直接在主线程外拿到Blob后处理需要用FileReader读取为ArrayBuffer再进行分片和哈希计算。具体实现可以这样模拟// upload-worker.js self.onmessage async (e) { const { file, chunkSize } e.data; const chunkCount Math.ceil(file.size / chunkSize); const chunks []; for (let i 0; i chunkCount; i) { const start i * chunkSize; const end Math.min(start chunkSize, file.size); const chunk file.slice(start, end); const buffer await chunk.arrayBuffer(); const hash await calculateHash(buffer); // 使用SparkMD5或Web Crypto chunks.push({ index: i, hash, chunk }); self.postMessage({ type: hashProgress, percent: (i 1) / chunkCount * 100 }); } self.postMessage({ type: chunks, chunks }); };笔试里更关注的是你能不能说出为什么要用Worker以及Hash计算的流程。如果只写用Worker处理但不解释主线程阻塞问题分数会打折。另外并发上传本身也有技巧不能把所有分片一股脑扔给后端控制并发数更合理。前端控制并发数的思路是写一个并发调度器维护一个任务队列每次最多同时执行N个上传任务。这个点美团笔试里也出现过我在后面编程题部分会再展开。3.3 微前端与工程化为什么中小厂也开始关注这个点微前端在前端热搜词里常年占一席之地美团笔试涉及微前端的意义本质上是在问当业务规模大到一定程度你会不会做合理的架构拆分和团队协作。微前端用于解决单体前端应用随着业务扩张变得庞大难维护的问题它的核心思路是让多个团队独立开发、独立部署自己的前端模块再由一个主应用统一组织加载。常见的方案有qiankun基于single-spa、module federationWebpack 5内置等。笔试里关于微前端的考法通常不是让你手写代码而是让你对比不同方案或者分析某个团队的架构合理性。你需要能说清楚主应用与子应用的隔离方式JS沙箱、样式隔离子应用如何进行路由注册和无感切换共享依赖与公共模块的处理策略qiankun的import-html-entry加载机制微前端引入后的部署成本与收益我个人的建议是不要只背概念自己搭一个最小demo跑一下看主应用加载子应用时Network面板里发生了什么这样笔试中遇到对应的选择题时你能更准确地判断哪个描述是对的。3.4 构建工具Vite与Webpack的对比美团前端笔试对构建工具的考察不算特别深但会因为候选人简历里写了熟悉前端工程化而加考一道对比题。最常见的考题是Vite和Webpack的核心差异。Webpack的核心是一个模块打包器它启动时会把整个项目所有的模块解析构建成依赖图再生成bundler这个过程在大型项目里会很慢。Vite则利用浏览器原生ES Module开发环境下不需要打包启动时直接按需编译当前页面用到的模块启动速度自然快很多。笔试可能会问Vite生产环境为什么还要打包答案是因为原生ES Module的请求数量过多而且浏览器对ES Module的兼容性和性能支持还不够理想所以生产环境还是要用Rollup或esbuild把模块合并压缩。这种题拼的就是你有没有真正用过而不是停留在概念层面。如果你在简历里写了使用Vite搭建项目那最好还能说出Vite中依赖预构建、HMR、import.meta.env这些API的使用感受。这样当面试官从笔试延伸到面试追问时你不会站不住。4. 编程题实战从读题到AC的完整链路4.1 编程题的考察逻辑不是算法竞赛是解决问题美团笔试的编程题和纯算法竞赛不一样。它不会出那种需要高级图论或复杂DP的题而是更偏向业务场景下的逻辑实现。往往题目描述里有一段业务背景然后要求你实现某个功能这段背景不是废话它决定了你需要选择什么方案。举个例子如果题目要求实现一个带并发限制的异步任务调度器考的就是你在移动端上传多个文件、或同时请求多个接口时能不能控制并发数量避免拖垮服务器。这种需求在算法题集里找不到但在工程场景里极其常见。解题的关键是不要直接上手写代码先花3-5分钟拆解题目要求明确输入输出格式、边界条件、时间空间复杂度要求。很多人时间不够用是因为拿到题目就敲代码结果敲到一半发现对需求理解错了只能重写。4.2 经典题解并发控制调度器这道题是美团笔试里出现频率极高的题目。核心要求是实现一个类Scheduler它能保证最多同时执行两个任务每当一个任务完成就从待执行队列中取出下一个任务执行。class Scheduler { constructor(limit 2) { this.limit limit; this.activeCount 0; this.queue []; } add(promiseCreator) { return new Promise((resolve) { // 把任务封装进一个函数resolve暴露给外部 const task () { this.activeCount; promiseCreator() .then((res) { resolve(res); }) .finally(() { this.activeCount--; this.next(); }); }; if (this.activeCount this.limit) { task(); } else { this.queue.push(task); } }); } next() { if (this.queue.length 0 this.activeCount this.limit) { const task this.queue.shift(); task(); } } } // 使用 const scheduler new Scheduler(2); const timeout (time, value) () new Promise((resolve) { setTimeout(() resolve(value), time); }); scheduler.add(timeout(1000, 1)).then(console.log); scheduler.add(timeout(500, 2)).then(console.log); scheduler.add(timeout(300, 3)).then(console.log); scheduler.add(timeout(400, 4)).then(console.log);按照这个逻辑任务1和任务2会立即开始因为限制是2任务3要等任务1或任务2完成才能启动最终输出顺序取决于每个任务实际执行时间而不是添加顺序。这里有个关键细节add方法返回的Promise要在任务真正执行完后才resolve所以封装task时不能直接执行promiseCreator()而是要放在一个回调里把resolve保留下来等promiseCreator().then触发后再resolve这样外部await scheduler.add(...)拿到的是任务完成后返回的值。这个细节在笔试里漏掉会导致结果全部undefined。4.3 防抖、节流与移动端手势的变种题不要以为防抖和节流已经老掉牙美团笔试很擅长给它套一层移动端业务外衣。比如实现一个移动端列表滚动节流函数保证滚动停止后只触发一次请求且要处理快速滚动时的竞态。防抖的本质是延迟执行如果事件在延迟时间内再次触发则重新计时。节流的本质是限制执行频率在一段时间内最多执行一次。笔试里容易混的是两者的适用场景搜索框输入适合防抖因为用户停顿后再请求而滚动加载更多适合节流因为滚动过程中需要持续判断是否到底部但不需要每次都触发。移动端手势ID和坐标获取也是一类变种题。比如实现一个简易的捏合缩放手势需要监听两个触摸点的touchmove计算两个点的距离变化进而调整目标元素的scale。这种题考的是对touch事件中touches数组的使用以及几何计算能力。4.4 手写Promise与事件循环每次必考的基础题前端笔试没有一道手写Promise题都显得不完整。美团考的通常是Promise.all的手写实现或者Promise的链式调用与事件循环的执行顺序分析。手写Promise.all的核心在于接受一个可迭代对象返回一个新的Promise所有Promise都resolve后结果按传入顺序返回任何一个reject整体reject。边界条件之一是传入空数组时应该立即resolve一个空数组。function myPromiseAll(promises) { return new Promise((resolve, reject) { if (!promises || typeof promises[Symbol.iterator] ! function) { reject(new TypeError(Argument is not iterable)); 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); } }, reject); }); }); }注意我用了Promise.resolve(promise)做了一层包装这是为了让myPromiseAll可以处理普通值而不是只有Promise的情况。另一个细节是results[index] value而不是results.push(value)这样才能保证返回顺序和传入顺序一致。事件循环的考察往往会结合setTimeout、Promise、async/await、requestAnimationFrame的执行顺序。基本规则是先执行同步代码再执行微任务队列Promise.then、async函数await之后的代码再执行宏任务setTimeout、setInterval。像这道经典题console.log(start); setTimeout(() { console.log(setTimeout); }, 0); Promise.resolve().then(() { console.log(promise1); }).then(() { console.log(promise2); }); console.log(end);输出是start - end - promise1 - promise2 - setTimeout。这道题考察的就是微任务和宏任务的优先级以及在一次宏任务执行完之后要先把当前微任务队列清空再去执行下一个宏任务。4.5 笔试中的陷阱题复盘我在第一批考试里踩过的坑第一部分题目里有一个关于var和let在for循环中创建闭包的题。题目要求输出数组中每个元素加1的结果但用了var声明循环变量典型的输出全是最后一个值。原因在于var没有块级作用域循环结束后变量已经变成最终值闭包捕获的是同一个变量。解决办法是把var改成let或者用IIFE包裹。这道题本身不难但我在考场上因为着急第一遍没审题直接用了var写了一个看起来正确的版本结果是全错复盘时才发现自己是把创建闭包的陷阱当成返回值一致写了。还有第二个坑CSS布局题里同时考察了flex: 1和min-width: 0的组合场景。移动端页面经常出现父容器是flex布局子元素文字过长不换行导致父容器被撑破的情况。flex: 1的默认值是1 1 0%其中1 1允许子元素在必要时缩小但如果子元素内部有长串字符或默认white-space: nowrap它自身的min-width: auto仍然不允许其小于内容宽度结果就是父容器被撑破。解决办法是给子元素设置min-width: 0或overflow: hidden。这道题我在当时只答出了flex: 1的伸展比例没有把min-width: 0写进去应该扣了一部分分。另外一个值得提醒的陷阱是选择题里关于移动端1px边框问题的方案判断。题目里列出了4个方案其中一个是直接设置border: 0.5px solid #eee我当时凭直觉排除了它但实际上在部分支持小数的浏览器和WebView里0.5px是可以正常渲染的并不是完全不可用。正确做法是把它作为兼容性不可靠选项而不是完全错误选项。如果题目是单选需要结合其他选项判断出题人的意图。5. 从笔试到Offer春招冲刺阶段的备考规划与心态调整5.1 时间线规划春招笔试前我应该做什么春招的节奏非常紧凑第一批笔试往往在开春后很快开始中间留给你的准备时间并不多。如果你现在还在准备阶段我建议按倒推法来规划时间线以笔试日期为终点往前推四周。第一周做基础能力摸底把所有知识点过一遍标记薄弱项。第二周和第三周针对薄弱项集中突破每天至少留3个小时给笔试准备其中1小时用来刷选择题基础知识2小时用来做编程题。第四周用来做套题模拟和复盘刷一到两份完整的往年笔试回忆题计时并模拟真实考试环境。如果你不是应届生、只是日常调技术栈安排可以灵活一些但核心思路是不变的笔试准备不是把知识点从头到尾背诵一遍而是找到自己不会的题逐个击破。5.2 如何选择刷题来源与资料市面前端刷题资料非常多但很多是面试题汇总整理并不完全适用于笔试场景。笔试更重视代码实现所以我建议把刷题来源分成三块第一块是基础编程能力用LeetCode的简单和中等等级题目保持手感重点关注数组、字符串、链表和栈队列相关的题目贪心和DP可以放一放除非你已经学有余力。第二块是前端专项编程包括手写Promise、防抖节流、深拷贝、数组去重、事件总线、订阅发布模式、虚拟DOM的diff简化版等。这类题在掘金、CSDN上有很多整理但效率最高的方式是自己先动手实现一遍再对照标准答案看差异。第三块是项目实践找一个移动端的小项目练手比如做一个移动端的待办事项应用覆盖到用户登录、列表渲染、数据持久化、接口联调、页面性能优化、真机调试这些环节。即使这个项目很小只要你在笔试的简答题里能引用其中踩过的坑和优化方案给面试官的感受会比背八股文强很多。5.3 笔试中常见的时间分配策略美团笔试的总时长一般是90分钟到120分钟题量通常包括20道左右的选择题和2到3道编程题。从我的实战经验来看选择题的控制时间应该尽量压缩在30到40分钟内为编程题留下充足时间。编程题的做题顺序也有讲究。不要按照题号顺序做先花2分钟把几道编程题都读一遍挑一道自己最有把握的先写。这样能保证你至少有一道题是完全AC的心态会稳很多。如果先做最难的题卡住之后容易心态崩后面的送分题都写不顺。时间分配表格供参考时间段任务目标0-10分钟浏览全部题目标记难易对整个试卷有全局认知10-40分钟完成选择题和填空题基础题拿稳不在难题上死磕40-60分钟完成第一道编程题保证AC一道60-80分钟完成第二道编程题争取AC或部分通过80-90分钟回查答案检查选择题修正粗心导致的失分5.4 笔试前夜和考场中的心态控制笔试考的不只是知识储备心态非常影响发挥。我身边有同学平时强得很但一到线上笔试就紧张选择题明明会做的也选错编程题大脑一片空白。给你的建议是笔试前夜不要再接触新题了把之前做错的题翻一遍早点休息保证第二天脑子清醒。考试开始要检查网络环境、浏览器版本、摄像头权限这些硬件问题。尤其是线上笔试万一写代码写到一半网断了整个人都会慌掉。提前半小时进入考试系统做环境检测确认无误再开始。考试过程不要频繁看时间也不要被旁边人提交的影响。线上笔试你没法知道别人的进度只要按自己的节奏把会做的题都做完就足够了。很多企业笔试本来就是海选性质通过门槛没有想象中高核心是把基础题做对、编程题AC一道就已经能在同场竞争者中排到前面了。5.5 笔试结束后的跟进要不要复盘很多人考完笔试就彻底不管了这是很大的浪费。笔试题目虽然是分批的但考点高度相似。你考完趁记忆还热乎立刻把题目回忆出来对照答案看看自己错在哪里然后针对每个错题标注出对应的知识点在下一批笔试前集中补。我自己就习惯做一份错题本不仅记录正确答案还会在下面写清楚我当时为什么会选错。复盘还有一重价值如果笔试通过了接下来面试官很可能会拿着你的笔试答卷来问你在编程题里的解法、边界条件处理、代码风格都会被再次审视。提前复盘能让你在面试时对自己的答案了如指掌不会出现我都忘了我当时写的什么这种尴尬情况。5.6 个人化和经验性的补充笔试之外别忘了自己的项目最后想说一点笔试只是春招通关的第一关它的作用是筛选出基础合格、有潜力的候选人。但真正决定Offer的是后续的面试和你的项目经历。所以不要把所有精力都扑在刷题上一定要留出时间梳理自己做过的东西尤其是那些能体现移动端性能优化、工程化思维、真机调试能力的项目。我在美团笔试中能比较从容地做完移动端适配、ECharts tooltip、大文件分片上传、并发控制这类题很大程度上得益于当时花了很多时间在移动端页面性能优化上。你踩过真实的坑才能在考场上一眼看穿出题人想要什么答案。这也是我反复在说笔试考的其实是工程思维的原因。希望这篇复盘能给你一些参考祝你春招顺利。