2025年秋招比往年来得更早一些。8月中旬美团全栈岗第一批笔试就悄悄上线了。看到群里有人调侃“第一批笔试就当试卷模拟器”其实这话只说对了一半——美团笔试的题型和难度在互联网大厂里属于比较有代表性的题型稳定、考法传统中带着业务敏感度非常适合拿来当全栈岗的标尺。这篇内容我就以2025年秋招美团全栈岗第一批笔试为主线把整场笔试的题型分布、算法题复盘、前后端考点、场景设计题的答题思路全部拆开来讲同时补上我对这套笔试的备考建议和踩坑记录。无论你是正在准备秋招的2026届学生还是打算转全栈的开发这篇内容都能帮你把美团笔试的脉络摸清楚。先交代一下背景。2025年美团秋招全栈岗第一批笔试形式依旧是线上笔试时长120分钟题目分为三个部分计算机基础选择题、编程题、业务场景设计题。整体难度中等偏上选择题覆盖前端、后端、网络、数据库、操作系统多个方向编程题四道从字符串处理到动态规划梯度明显最后一道场景设计题考的是外卖业务下的接口设计与故障排查思路。整场笔试做下来的感受是美团确实在认真筛“能干活”的人题面里处处都是业务影子不是死记硬背能蒙过去的。如果你正准备投美团全栈岗或者想拿美团笔试练手下面这六部分内容建议收藏了慢慢看。1. 笔试整体情况题型、题量与时间分配1.1 题型构成和分值占比美团全栈岗第一批笔试的题型结构如下表所示题型题量分值占比建议用时单选题计算机基础业务理解10-12道约20%15分钟多选题基础易错项3-5道约10%10分钟编程题4道约50%70分钟业务场景设计/简答1道约20%25分钟刚看到这套结构时我的第一反应是美团把笔试重点压在了算法题上但选择题和场景题也不是随便选选就能拿分的。特别是多选题错选、漏选都不得分这就逼着你把知识点吃透不能靠感觉蒙。编程题四道按照惯例从简单到困难排序前两道属于“热身题”后两道是真正的分水岭能不能进面试基本看后两道的AC情况。时间分配上我建议所有题目先从头到尾扫一遍选择题拿不准的先标记跳过编程题从第一道开始往后做。我这次笔试实际用了110分钟最后留了10分钟检查选择题卡了两个不确定的编程题四道全部通过场景题写得比较完整整体节奏还算舒服。如果你平时刷题量不够编程题很容易出现“第二道卡半小时第四道来不及看”的情况所以前两道简单题必须快准狠。1.2 笔试平台和答题环境美团笔试用的第三方在线平台支持本地IDE调试编程语言不受限制Java、C、Python、JavaScript都可以。这里有一个非常实用的经验提前把你最熟悉的语言模板准备好比如Java的输入输出模板、JavaScript的readline模板开考后直接复制改逻辑省下敲模板的时间。平台还有一个容易被忽略的点——代码编辑器的默认设置和本地IDE不同没有代码补全也没有自动缩进。如果你平时依赖IDE的自动补全建议提前在线平台上做几套模拟题适应一下。另外笔试过程中如果网络断开或页面卡住千万别慌第一时间截图保存代码然后刷新页面重新进入代码一般不会丢但心理压力会很大所以平时练习时就要养成一边写一边保存的习惯。1.3 选择题考察方向和易错点美团的选择题不是纯八股它会结合业务场景出题。比如有一道题考的是“某商户信息在App端获取失败排查思路的第一步应该是什么”选项里有“查看DNS解析是否正常”“检查服务端日志”“直接重启网关”“查看商户缓存是否过期”。这就是典型的美团风格——把技术点放到具体业务问题里。从我这批笔试的选择题来看高频考点集中在以下方向计算机网络TCP三次握手、HTTP状态码、HTTPS握手流程、DNS解析过程操作系统进程和线程区别、死锁条件、虚拟内存、页面置换算法数据库索引失效场景、事务隔离级别、MVCC原理前端基础事件循环、闭包、原型链、浏览器渲染流程后端基础进程间通信方式、分布式一致性问题、消息队列选型多选题里有一道关于“索引失效场景”的题选项设置了四个很容易混淆的情况比如“对索引列使用函数”“隐式类型转换”“OR连接非索引列”“order by索引列”。正确答案是前三个但很多人会把“order by索引列”也选进去——实际上order by走索引的情况很常见只要没有额外的排序开销就算合理使用。这种细节题就是用来拉开分数差距的。2. 编程题复盘四道题全思路拆解2.1 第一题订单状态流转判断哈希表模拟这道题属于签到题题面大意是给定一批订单的状态流转记录每条记录格式为“订单ID 旧状态 新状态”判断哪些订单的状态流转是非法的。订单状态定义了一个有限状态集合合法的流转路径会在题目中给出。拿到题后先别急着写代码第一步是把合法的状态流转关系转化成一张哈希表。我用的是JavaScript// 定义合法状态流转表 const validTransitions { CREATED: [PAID, CANCELLED], PAID: [DELIVERING, REFUNDING], DELIVERING: [COMPLETED, REFUNDING], REFUNDING: [REFUNDED], COMPLETED: [], CANCELLED: [], REFUNDED: [] }; function checkOrderTransitions(records) { const illegalOrders new Map(); for (const record of records) { const [orderId, oldStatus, newStatus] record.split( ); const allowedNext validTransitions[oldStatus] || []; if (!allowedNext.includes(newStatus)) { if (!illegalOrders.has(orderId)) { illegalOrders.set(orderId, []); } illegalOrders.get(orderId).push(${oldStatus}-${newStatus}); } } return illegalOrders; }这道题的核心是哈希表的应用不涉及复杂算法但要注意一个坑同一个订单可能出现多次流转比如“CREATED-PAID”合法“PAID-DELIVERING”也合法但如果“DELIVERING-CREATED”出现了那就是非法。所以不能用一次非法来判断整条链而是要把当前状态实时更新再看下一步是否合法。很多人在这一步踩坑就是因为直接把订单初始状态拿来比对忽略了状态是动态变化的。另外一个细节输入数据可能是乱序的比如订单A的“PAID-DELIVERING”出现在“CREATED-PAID”之前这时候不能简单用数组顺序判断需要先把同一订单的记录按时间戳排序再逐条检查。这道题整体不难但时间戳排序这个点能筛掉一部分粗心的人也是业务系统里状态机设计的常见难点。2.2 第二题骑手配送区间覆盖排序双指针第二题大意是给定一批骑手的配送坐标位置每个骑手可以服务一个固定长度的区间问至少需要多少个区间才能覆盖所有配送点。实际上是经典的“区间覆盖”问题变体。思路是先把坐标排序然后从最左边的点开始用一个长度为L的区间去覆盖尽可能多的点覆盖不到时再新开一个区间。核心代码如下function minDeliveryIntervals(points, L) { points.sort((a, b) a - b); let count 0; let i 0; while (i points.length) { count; const start points[i]; // 尽可能覆盖更多点 while (i points.length points[i] start L) { i; } } return count; }这道题看起来简单但有个容易犯的错排序后新开区间时不是从“当前未覆盖的最左点”开始而是错误地以上一个区间的右端点作为新起点导致区间浪费。正确的做法是每次新开区间都以第一个未被覆盖的配送点作为起点然后向右扩展。美团出这道题的意图比较明显骑手配送范围划分是外卖业务的基础问题背后对应的就是贪心算法里经典的“区间覆盖”模型。如果你能答出“这题本质是区间覆盖问题和种树、路灯覆盖是同一种模型”面试时会被认为有业务抽象能力。笔试虽然只考代码但解题时在注释里写出思路面对面试官时也能展示你是真懂而不是背题。2.3 第三题商家关联关系最短路径BFS第三题是一道图论题题面是给定商家之间的关联关系比如共享供应链、合作活动等求两个商家之间的最短关联跳数。如果没有任何关联关系返回-1。商家和商家之间的关系可以看作一个无向图所以这题就是标准的BFS求无权图最短路径。难点不在BFS本身而在于图的构建——输入给的是边列表需要自己转成邻接表。参考实现function shortestPath(edges, n, start, target) { // 构建邻接表 const graph Array.from({ length: n }, () []); for (const [a, b] of edges) { graph[a].push(b); graph[b].push(a); } // BFS const visited new Array(n).fill(false); const queue []; queue.push(start); visited[start] true; let steps 0; while (queue.length) { const size queue.length; for (let i 0; i size; i) { const node queue.shift(); if (node target) return steps; for (const neighbor of graph[node]) { if (!visited[neighbor]) { visited[neighbor] true; queue.push(neighbor); } } } steps; } return -1; }这题考察的是基础的图遍历但在全栈岗笔试里出现说明美团确实看重业务场景中的关系链分析能力。商家人脉关系、用户社交关系、骑手协同网络本质上都是图结构。我建议刷题时要把BFS和DFS的模板练得滚瓜烂熟特别是邻接表的构建不能卡壳否则这种题本来能做对却因为基础不扎实丢分太可惜。另外要注意这题的边界条件start等于target时应该返回0而不是1商家数量n可能很大图要控制在O(VE)的空间复杂度内队列用数组模拟时要意识到shift操作是O(n)的数据量大时会有性能问题可以换用索引指针的方式优化。2.4 第四题高峰时段窗口最大订单金额滑动窗口单调队列第四题是整个笔试的压轴题。题面大意是外卖平台在高峰期会有一系列订单到达每个订单有到达时间戳和金额给定一个固定时间窗口K求在所有长度为K的时间窗口内订单总金额的最大值。要求时间复杂度尽量低。这题的正解是“滑动窗口前缀和”或者更进阶的“单调队列求区间最大值”。先说前缀和版本function maxWindowSum(orderTimes, orderAmounts, K) { const n orderTimes.length; const prefixSum new Array(n 1).fill(0); for (let i 0; i n; i) { prefixSum[i 1] prefixSum[i] orderAmounts[i]; } let res 0; let left 0; let right 0; while (right n) { while (orderTimes[right] - orderTimes[left] K) { left; } const windowSum prefixSum[right 1] - prefixSum[left]; res Math.max(res, windowSum); right; } return res; }这里有一个关键点订单到达时间不一定是均匀分布的窗口内订单数量不固定所以不能简单用“每K个订单作为一个窗口”而要根据时间戳动态调整左右边界。如果题目改成“每个订单的金额可能为负数”那就要用单调队列来解决这也是为什么美团选择这题作为压轴的原因——它可以从滑动窗口升级到单调队列考察的层次感很强。我的做题策略是先用前缀和写出一个能通过大部分case的版本确保基础分拿到再去追求单调队列的优化版本。实际笔试时如果时间不够朴素版本配合优化的滑动窗口边界判断也能过70%左右的测试用例。3. 前端核心考点从手写题到工程化3.1 必考手写题防抖、节流、Promise.all美团前端相关笔试题基本绕不开手写题最常考的是防抖、节流和Promise.all。以“输入框搜索商户”为例用户在搜索框中连续输入时不能每敲一个字符就发一次请求需要等用户停止输入300ms后再请求这是防抖而页面滚动时每隔一段时间执行一次逻辑这是节流。防抖和节流的实现代码几乎每个前端人都背过但真正到了笔试现场能把边界情况处理好的不多。比如防抖的this指向、参数透传、立即执行选项这些细节是否处理干净一眼就能看出是否有实际项目经验。// 带立即执行选项的防抖 function debounce(fn, wait 300, immediate false) { let timer null; return function(...args) { const context this; if (immediate !timer) { fn.apply(context, args); } clearTimeout(timer); timer setTimeout(() { fn.apply(context, args); timer null; }, wait); }; }Promise.all的手写版本同样高频。美团特别喜欢在笔试里考察“用Promise实现一个控制并发数为N的调度器”这其实是Promise.all的进阶版背后对应的是前端并发请求控制的真实业务场景。核心思路是用一个任务队列每次取N个任务执行执行完一个再从队列里取一个补充。3.2 浏览器渲染与性能优化全栈岗位的笔试题里浏览器相关的问题通常不会直接出编程题而是在选择题里出现。但从我这次笔试的经验来看了解浏览器的完整渲染链路对做场景设计题也有帮助。从输入URL到页面展示这个过程的每一步都可能出现性能瓶颈DNS解析慢、TCP连接慢、SSL握手耗时、首包时间过长、HTML解析阻塞、CSS阻塞渲染、JavaScript阻塞解析。美团这种体量的App前端性能优化已经不是“减少图片体积”这种层面了而是深入到HTTP/2、HTTP/3的选用、资源预加载、骨架屏、流式渲染、边缘计算等方案。笔试中考察性能优化的主要形式是让你设计方案。比如“某个页面在弱网环境下首屏加载过慢你会怎么排查和优化”这种题回答时要有层次先量化指标看FCP、LCP、TTFB分别在多少毫秒再分层分析网络层看CDN命中率、接口耗时渲染层看JS执行时间、DOM节点数量优化时优先做收益高的体积压缩、路由懒加载、图片CDN加速、接口缓存这个回答框架在实际工作中同样适用。我见过太多人一上来就说“上SSR”“换框架”实际上大部分性能问题都是资源体积和接口耗时导致的框架层面的优化是最后一步。3.3 框架与工程化Vue/React对比与实际选型美团前端的主力框架是Vue和React都有具体到部门会不一样。笔试里不会考“Vue好还是React好”这种主观题但会通过选择题考察核心原理比如“Vue3的响应式原理是基于什么实现的”“React的Fiber架构解决了什么问题”。我的建议是把两个方面吃透一是框架的响应式原理或渲染机制二是组件通信方式。Vue3的Proxy响应式、React的不可变数据、函数组件和Hooks这些都是高频考点。笔试不会让你手写一个Vue响应式系统但会考“以下哪个操作会触发视图更新”“useEffect的依赖数组变化时执行顺序”这类细节题。工程化方面美团对webpack、vite、Rollup等构建工具的考察不算深但会考“热更新原理”“Tree Shaking生效条件”“Code Splitting的配置方式”。其中Tree Shaking生效条件是个经典易错点只有ES Module规范才能被静态分析CommonJS不行有副作用sideEffects的模块不能直接摇掉以及开启production模式后压缩器会移除死代码。这些细节没有实际配置过构建工具的人是答不出来的。3.4 大数据量渲染和虚拟滚动美团全栈岗的笔试题目里有一类题专门跟“商户列表”“订单列表”这种后台业务强相关——大数据量渲染。比如“商户管理后台需要渲染上万条订单数据直接v-for/渲染列表会导致页面卡顿你会怎么优化”。正确的回答不是“分页”这么简单而是要说出虚拟滚动的原理可视区域高度除以每项高度得到可见数量监听滚动事件计算起始索引渲染时只渲染可见项加上buffer区域同时用绝对定位撑起总高度。如果你能进一步说出“避免滚动抖动”“key不要用index”“列表项高度不固定时如何测量”这些细节面试官通常会另眼相看。4. 后端核心考点从并发到存储4.1 事件循环与并发模型对比后端笔试题的第一个高频考点是并发模型。美团的后端技术栈以Java为主全栈岗对Node.js也有一定考察。笔试中一道典型的选择题是“Node.js事件循环中以下哪个阶段执行setTimeout回调”答案是timers阶段但很多人会跟poll阶段、check阶段搞混。对全栈岗位来说理解Node.js事件循环和Java线程模型之间的差异比死记阶段划分更重要。Node.js是单线程事件循环适合I/O密集型任务Java是线程池阻塞I/O适合CPU密集型和复杂业务逻辑。美团这种业务场景下BFF层用Node.js做接口聚合层很常见核心交易链路的Dubbo服务还是Java全栈工程师的价值就在于能在这两层之间灵活切换。笔试中如果出编程题考并发大概率会考“写一个并发控制函数同时执行N个异步任务”。这个在上一节提到过是前端后端都可能考的公共点。我建议准备一个通用的并发控制模板面试时无论是“批量请求接口”还是“限制数据库并发连接”都可以套用。4.2 数据库索引与事务机制数据库部分的高频考点非常集中索引、事务、锁、慢SQL优化。美团笔试中有一道题考的是“以下哪些操作会导致索引失效”四个选项分别是“对索引列使用函数”“隐式类型转换”“OR连接非索引列”“使用索引列进行排序”。这道题我印象太深了因为第4个选项具有迷惑性——实际上正确排序是可以利用索引的但很多人会把它也选进去。另一个高频考点是事务隔离级别。美团特别喜欢考“MySQL默认隔离级别是什么”“可重复读和读已提交的区别”“幻读是怎么产生的”。这些知识点不仅要背定义还要能结合业务举例。比如外卖订单支付场景为什么用可重复读而不是读已提交——因为要保证同一事务内多次读取订单状态一致避免出现金额不对账的诡异问题。慢SQL排查是笔试也可能出现场景化题目的方向。比如“线上某接口突然变慢数据库CPU飙升你判断是慢SQL导致怎么定位”标准思路是通过慢查询日志找到耗时Top N的SQL然后explain查看执行计划重点关注type类型、索引使用情况、扫描行数。如果type为ALL或index说明没走索引就要分析是索引失效还是缺少索引然后针对性优化。这个排查思路在美团这种高并发场景下几乎是必用技能。4.3 Redis缓存三大问题与分布式锁美团业务的特点是读多写少缓存几乎是所有核心链路的标配所以Redis相关的知识点在后端笔试中占比很高。选择题里经常出现的问题是缓存穿透、缓存击穿、缓存雪崩的区别和应对方案。缓存穿透查询一个不存在的key请求直接打到数据库解决办法是布隆过滤器或者缓存空值缓存击穿某个热点key过期瞬间大量请求打到数据库解决办法是互斥锁或者热点key不设过期时间缓存雪崩大量key在同一时间段失效解决办法是过期时间加随机值或者用集群模式避免单点笔试中如果出场景设计题几乎一定会让你设计一个缓存方案。这时候不要只答“加缓存”三个字而要说清楚哪些数据需要缓存、缓存key怎么设计、过期时间怎么设置、缓存和数据库的一致性如何保证、缓存失效时如何降级。分布式锁也是高频考点尤其是“用Redis实现一个分布式锁要注意什么问题”。标准回答是setnxexpire的原子性操作、value设置唯一标识防止误删、使用Redisson的看门狗机制自动续期、主从架构下锁丢失的问题。如果能答到Redisson的公平锁和多级存储说明你真的在分布式环境里写过代码而不是只看了八股。4.4 消息队列与削峰填谷美团外卖业务在高峰期会有大量订单涌入消息队列是削峰填谷的核心组件。笔试中通常会考察消息队列的基本概念、选型和可靠性问题。“如何保证消息不丢失”这道题是经典三连生产者端确认机制、Broker端持久化、消费者端手动ack。“如何保证消息不重复消费”的答案则要落到业务幂等性上——比如订单状态机天然支持幂等消费端做去重表或者用Redis记录消费ID。而“如何保证消息顺序消费”则需要把同一订单的消息发送到同一个分区/队列中消费者单线程处理。这些考点并不难但需要你把概念落到具体场景里。比如美团的高峰期订单量暴增如果直接用同步接口调用会导致下游服务被流量打垮所以订单创建后先发消息由下游服务异步处理这就是典型的“削峰填谷”。我把这个场景写进了场景设计题里答起来就很有骨架了。5. 场景设计题与业务理解一道题看出你的全栈思维5.1 设计“商户详情页接口”的完整思路美团全栈岗的场景设计题通常是开放式的没有标准答案但一定会有明确的业务背景。我这批笔试的最后一题大致是“设计一个美团App商户详情页的接口需要包含商户基本信息、评分、菜品列表、评价摘要请画出你的技术方案并说明缓存策略和异常降级方案”。这道题的答题框架我是这样拆的第一层是接口设计明确返回结构。我会先定义一个大的响应体包含商户基本信息、评分、菜品、评价四个模块每个模块单独用子结构表示。考虑到调用方是App和H5两端接口设计要兼顾传输效率和扩展性数据量大时可以用字段裁剪或者GraphQL方案但笔试题里没必要扩展到这一步。第二层是数据来源分析每个模块的存储位置。商户基本信息变化频率低放Redis缓存key设计为“merchant:info:{id}”value用JSON序列化过期时间30分钟评分信息是统计聚合值可以异步计算后写入缓存菜品列表相对稳定同样走缓存评价摘要是通过ES或者数据库查询出来的适合做异步刷新。这里一定要体现出你对不同数据类型有差异化缓存策略的意识。第三层是降级和兜底。如果Redis挂了不能直接抛异常应该走本地缓存或者之间查数据库但要控制并发避免缓存雪崩把数据库打挂。App端还可以做客户端缓存接口失败时展示上一次的成功数据这就是“故障时优雅降级”思路。这种题目考察的不是你背了多少Redis命令而是你有没有完整的全栈视角——知道数据从数据库到缓存再到前端展示的完整链路。5.2 “商户信息获取失败”排查流程设计笔试中有一道多选题直接考了“某商户信息在美团App上获取失败你的排查步骤是什么”。这道题虽然没有让我写完整方案但我在准备时专门复盘过类似的线上问题把排查链路完整走了一遍。排查“商户信息获取失败”这类问题不能直接从商户服务开始排查要从用户请求的完整链路上游往下游逐层分析。第一步看客户端网络是否正常弱网环境下请求可能还没发出就超时了第二步看DNS解析和CDN加速是否生效如果域名解析到错误IP请求根本到不了服务端第三步看网关层是否有鉴权失败或者限流拦截第四步才到业务服务看商户服务是否正常响应日志中有没有异常堆栈最后还要检查数据库和缓存确认商户数据是否存在、缓存是否过期。这套排查思路在笔试答案里分条写出来就能看出你有线上问题处理经验。答题时要特别注意“先查缓存还是先查数据库”这个点正确做法是先确认缓存里有没有数据再看数据库因为缓存击穿会导致大量请求打到数据库反过来把数据库打挂。5.3 高峰流量下“接口限流与降级”方案设计场景设计题的另一个经典方向是应对高峰流量。比如“外卖平台午高峰期间某接口的调用量是平时的10倍你会怎么做”。这种题不能只答“加机器扩容”要结合成本和技术手段给出分层方案。流量入口层可以做接入层限流比如令牌桶算法限制单机QPS应用层可以做接口维度限流对核心接口和非核心接口设置不同的阈值再往下可以做服务降级比如评价摘要功能可以暂时关闭用固定文案替代保证主流程——商户信息和菜品列表——正常返回。全栈岗位回答这类问题时我喜欢加上前端的配合App端做数据预加载和本地缓存用户打开首页时提前拉取附近热门商户数据高峰期即使接口熔断用户依然能看到部分内容。这样前后端联动的方案是面试官比较认可的全栈视角。6. 备考建议与刷题避坑指南6.1 秋招时间线和备考节奏结合2025年秋招第一批笔试的情况我建议2026届学弟学妹按照以下时间线准备7月中旬到8月中旬是“打底期”这个阶段不用急着投简历把算法基础巩固一遍特别是链表、树、图、动态规划这些高频题型。同时把计算机网络、操作系统、数据库的八股梳理一遍不用背到逐字逐句但核心概念要能用自己的话讲明白。8月中旬开始“刷题期”每天在力扣上保持2-3道题的手感优先刷美团、字节、阿里等大厂近三年的真题。9月份是“笔试面试期”这个阶段要开始投递简历并参加笔试同时准备行为面试和技术深挖的项目经验。很多人在7月份就开始焦虑“别人已经拿到offer了”这种心态对备考没有帮助。秋招是持久战第一批笔试只是开始后面还有第二、第三、第四批美团甚至可以多次投递不同部门机会比想象中多。6.2 全栈项目怎么准备才能过简历筛选美团全栈岗的笔试虽然不直接考项目但项目经验是简历筛选的重要环节。如果你准备的是“企业级后台管理系统”这类全栈项目不要只写“用了Vue3Spring Boot实现了一个后台管理系统”这太泛了。我建议从三个维度包装全栈项目。第一是业务复杂度说明项目解决的实际问题是什么比如“设计了一套基于RBAC的权限管理模块支持多租户数据隔离”第二是技术亮点比如“实现了前端路由懒加载和组件按需引入首屏加载时间从4s降到1.2s”“后端接口平均响应时间从800ms优化到200ms主要通过索引优化和多级缓存实现”第三是工程化能力比如“配置了ESLintPrettierCommitLint规范项目代码”“使用Docker一键部署到测试环境”。不要小看这些看似简单的描述它们会在简历筛选时让面试官觉得你是有真实工程经验的而不是只做过课程设计。美团全栈岗特别看重“能独立搞定一条链路”的能力哪怕是一个小的业务模块只要你能把前端、后端、存储、部署讲清楚就是非常亮眼的项目经历。6.3 笔试现场的实用技巧和心态调整最后分享几个我在美团笔试现场总结的实用技巧。第一是编程题的时间分配。如果前两道题15分钟内没做出来建议先跳过做后面的因为前两道简单题卡住通常是因为题目读错了或者边界条件没想清楚硬磕会浪费大量时间。我一般是拿到全部题目后先花3分钟扫一遍评估难度梯度然后按顺序做每道题最多25分钟超时就先写核心思路和伪代码尽量拿过程分。第二是选择题的“排除法”和“代入法”结合使用。多选题不确定的选项可以先标记但不要在一个选项上纠结超过30秒。我的经验是美团的多选题里两个选项之间模糊不清时选“看起来更保守”的那个比如涉及“一定”“必须”“所有”这种绝对化表述的选项通常是错的概率更大。第三是心态。笔试过程中遇到完全没思路的题很正常这时候深呼吸先把题目翻译成最朴素的模型——是图论还是动态规划、是字符串还是数学计算然后从最暴力的解法开始想哪怕是O(n^2)的解法也可以先写出来再逐步优化。很多时候写着写着思路就通了。另外笔试结束后一定要把题目记下来特别是自己没做出来的部分。美团笔试的题型风格每年都有延续性这次考了滑动窗口下次大概率还会出现在区间问题里。把每场笔试的错题整理成笔记比多刷十道新题更有价值。我自己考完这场美团全栈岗第一批笔试后的最大感受是这已经不是“背八股刷LeetCode”就能轻松过关的时代了。美团在题目里塞满了业务影子从订单状态机到商家关联关系从高峰滑动窗口到商户详情页接口设计每一道题都在暗示“你未来的工作就是解决这些真实问题”。所以备考时别光顾着刷题多想想这些题背后的业务场景等你真正进入笔试考场时会发现很多题目都似曾相识。