上周 LeetCode 周赛 430 一结束，就有个准备秋招的学弟给我发了条消息，原话大概是："哥，现在笔试还刷 LeetCode 还有用吗？我昨晚做模拟题，一道题读了三遍都不确定它在问什么，感觉跟我刷的题完全不是一回事。"
我太懂这种感受了。他说的"不是一回事"，并不是题变难了，而是题变"厚"了。以前笔试是一眼能看出考点，现在则像读需求文档；以前只要你AC了就万事大吉，现在笔试平台会记录你每个测试用例的耗时、内存，甚至代码本身会被面试官调出来当面复盘。标题里那个"90%"我没法精确统计，但说实话，按我这些年看过的笔试反馈，倒在这三类题上的人，比例真不比90%低多少。
这篇就把我觉得最要命的三个陷阱掰开讲清楚，然后告诉你应该怎么调整刷题和上考场的策略。
1. 先搞清楚：笔试不是不考算法了，是换了一种考法
很多人的第一反应是"大厂不考算法了？"——恰恰相反，算法不但考，而且考得更细、更隐蔽。变化的不是知识范围，而是题目外衣和评价标准。
1.1 一个"旧题新考"的样本
拿最经典的 LRU 缓存来举例。老题库里的描述很短："设计并实现一个满足 LRU 约束的数据结构。"三行读完，直接写代码。
现在的大厂笔试题会长什么样？我整理过真实反馈，大概是这种感觉：
直播间的热门礼物列表需要在短时间内被高频读取，同时要实时淘汰掉已经过气的礼物，保证内存占用不超过 X MB。请设计一个存储结构，支持在 O(1) 时间内完成查询和更新……
你看，本质还是"实现一个 LRU"，但多了一层业务包装。有人读完就懵了：这考的是系统设计还是算法？其实剥掉外壳，考点一点没变：双向链表 + 哈希表。
再比如 LeetCode 上那道 875 题"爱吃香蕉的狒狒"（Koko Eating Bananas），一直被归类为经典二分答案入门。这类题的价值恰恰在于它自带一个故事外壳——你要从"几小时内吃完"这种场景描述里，抽象出"速度 K 与用时单调递减"的关系，然后套二分。大厂笔试现在大量采用这种"场景 + 算法"的复合题型，你光会背模板不够，还得会从题面里把模板"拽"出来。
1.2 三个让考生不适应的变化信号
我把最近几批笔试反馈归了归类，真正让人翻车的不是题目难，而是三个变化信号没接住。
第一个信号是题干变长。以前一道题三五行，现在一道题能写满半屏甚至一屏，夹杂着业务术语、数据规模限制、甚至输入输出的奇怪格式。这考验的是耐心和信息提取能力，很多人不是不会做，是压根没读懂。
第二个信号是约束条件变硬。题目里直接写明"空间复杂度必须为 O(1)""整体时间复杂度必须为 O(n log k)"，这类硬性要求会直接把你的"第一反应解法"判死。比如你刚想用堆 + 哈希表做 TopK，题目立刻要求"不能用内置优先队列"，你怎么办？
第三个信号是评价维度变多。现在有些大厂笔试平台不只统计最终正确率，还记录每组测试用例的运行时间和内存占用。极端情况下，甚至会出现"所有用例通过但总耗时超限判失败"的机制。换句话说，你的解法不再只是"对与错"的二分，而变成了"好不好"的梯度评分。
这么说吧，LeetCode 并没有退出历史舞台，但它更像健身房里的器械，你练的依然是肌肉力量；大厂笔试则像是实际运动场上的比赛，同一块肌肉得在复杂规则下发挥。接下来逐个拆这三类让人摔跟头的题。
2. 陷阱一：业务包装题——从"裸算法"到"披着场景的算法"
2.1 这类题的真实长相
这类题最显著的特征是：题干必须给你编一个业务故事。我整理几个高频出现的场景原型，你对照着看就明白了。
- 推荐系统场景："给出用户的历史点击序列，要求返回每个用户最常消费的前 K 个内容。"剥开是 TopK + 频率统计，对应堆或快速选择。
- 订单调度场景："系统中有大量订单，每个订单有超时时间戳，要求高效清理已超时订单。"剥开是优先队列 / 时间轮 / 有序集合的过期淘汰。
- 日志合并场景："多个服务产生有序日志，要求按时间全局合并后输出前 N 条。"剥开就是多路归并。
- 任务编排场景："一批任务存在依赖关系，部分任务只能在其他任务完成后执行，要求输出一种可执行顺序。"剥开就是拓扑排序。
你看，业务故事千变万化，但算法骨架就那么几十种。这类题真正难的不是解法，而是你能不能平静地把故事读完，然后给它"祛魅"。
2.2 为什么大厂热衷这么出题
从面试官的角度看，这几乎是必然的选择，背后有三层逻辑。
首先是防背题。LeetCode 热门 100 题早就被翻烂了，直接出原题等于给背题党送分。业务包装成本极低，效果却立竿见影——没真理解算法本质的人，题面一换就露馅。
其次是筛选工程抽象能力。你写业务代码的时候，面对的是需求文档、产品描述、线上故障，你需要从中抽取关键逻辑，落成数据结构和算法。笔试加一层业务包装，恰恰是在模拟真实工作状态。
最后是考察结构化思维。能不能把一段混乱的描述拆成"输入、输出、约束、目标"四个要素，这在任何岗位都是基本功。有些人在故事面前乱了节奏，这不只是算法问题，更是信息处理能力的短板。
2.3 破题方法：三步剥离法
面对业务包装题，我自己的方法是固定的三步，你也可以直接拿去用。
第一步，圈出题干里的"行为动词"。几乎每道题都有核心动作：缓存、删除、合并、排序、找最大、判依赖、求连通。把这些动词抄下来，你就把故事小说读成了操作指令。
第二步，把业务名词映射到数据结构。用户 ID、订单 ID、物品 ID 基本都是"键"；时间戳基本都是"序列"或"排序依据"；"前 K 个""最大的""最热的"全部指向堆或快速选择；"依赖关系""先后顺序"指向图论。
第三步，根据输入规模决定算法档次。数据量在百级、千级直接暴力；万级考虑 O(n log n)；百万级以上就要想 O(n log k) 甚至 O(n) 的解法。这一步能帮你避免"一上来就优化过度"或者"暴力跑死"两个极端。
以"爱吃香蕉的狒狒"为例：看到"最小速度 K"，基本能锁定二分答案；再看到"H 小时内吃完"，确认需要在二分里套一个 check 函数去模拟每堆香蕉的吃法。这时候故事外壳已经完全脱落，剩下的就是二分的标准骨架。
我个人的体会是，这一步剥离做得熟练以后，刷题速度会明显变快。因为你不只是在"记住某道题的答案"，而是在训练一种通用的题目阅读器。
3. 陷阱二：复杂度约束题——会解不等于能解
3.1 一个"会做却拿不到分"的典型镜头
第二类坑，不是看不懂题，而是看懂了题但解法不过关。我拿一道非常经典的题来说：给定一个大文件，里面有几百万行日志，每行包含用户 ID 和访问次数，要求返回访问次数最高的前 K 个用户。
正常训练过的人，第一反应是"哈希表统计 + 全局排序"，然后立刻掏出 PriorityQueue 把所有元素灌进去排序，最后截取前 K 个。在小数据量下，这个解法没有毛病；但在几百万量级下，它的问题就很明显——全局排序的时间复杂度是 O(n log n)，空间上还要保留全部 n 个元素。笔试题的硬约束可能就是"时间复杂度 O(n log k)，空间复杂度 O(k)"。
于是大量考生就栽在这里：明明知道这题怎么做，但一提交，要么内存超限，要么总耗时超标。这就是"会解"和"能解"之间的差距。
3.2 时间与空间的博弈：题目在逼你做工程决策
为什么大厂一定要把约束写得这么死？我做过几次内部出题讨论，大家共识出奇一致：真实系统里没有无限资源。线上服务的 Redis 内存是有配额的，消息队列的积压是有容量上限的，接口的 P99 时延是有 SLA 的。你在笔试里写一个"先全部装进内存再排序"的解法，等于在真实系统里做了一次高风险的内存透支。
这类题目考察的其实是工程权衡能力。典型场景包括：
- 用空间换时间：比如哈希表 O(1) 查询，但牺牲部分内存。
- 用离线换在线：比如把在线实时 TopK 改成离线批次统计，用小顶堆把堆顶卡在 K 附近，空间永远只有 K。
- 用预处理换响应：比如对日志做预先排序或索引，查询时直接取前 K 个。
处理这类题，我的核心建议是：先写暴力，再分析瓶颈，再针对性优化，而不是一上来就奔向最优解。有些人怕写暴力被扣分，实际上在笔试里，能正常运行出结果的暴力解，通常能拿到相当一部分的过程分。更重要的是，先把暴力写对，能验证你对题目的理解没有跑偏，后续优化才谈得上。
3.3 现场解题的通用顺序
我自己在笔试题上有一套固定的落地顺序，分享给你参考。
第一步，用注释把题目翻译成人话，包括输入是什么、输出是什么、数据规模大概是多大。这一步能极大概率避免理解偏差。
第二步，判断一个可接受的时间复杂度上限。假设数据规模是 n，看题目时限（一般 1 到 2 秒），可以粗略估算：n 在 10^5 左右要 O(n log n)，n 在 10^6 以上基本要 O(n)，n 在 10^3 以下可以偏暴力。
第三步，写出暴力版本并自己在脑内跑一遍小样例。这一步不是浪费时间，而是建立基准。就算最后你优化失败，至少有一个正确但慢的兜底答案。
第四步，标记暴力解法里的瓶颈操作。是排序太慢，还是查找太慢，还是重复计算太多，针对瓶颈选择优化策略：排序太慢换堆或快选，查找太慢换哈希或前缀和，重复计算太多换 DP 或双指针。
第五步，在提交前，把两种解法的复杂度都写进注释里。原因待会儿在第四个陷阱里细说。
这套流程的本质是强迫自己"先想清楚再动手"，而不是读一遍题就埋头敲。很多翻车现场都是因为跳过了前面的步骤，直接凭经验选了一个"看起来正确"的数据结构。
4. 陷阱三：代码质量题——从 AC 到"像样交付"
4.1 从"AC"到"AC + 可读"的评价变化
如果说前两类陷阱坑的是算法能力，第三类坑的就是所有只刷题、不写工程的考生。
过去我们对笔试代码的要求就一条：AC。但现在不少公司会在笔试通过后，把代码调出来人工看一眼，面试现场也会说"你先讲讲笔试第三题你的思路"。那一刻，你代码里的变量名 a、b、tmp，写了 50 行的主函数，没有任何边界检查，都会赤裸裸地暴露在面试官面前。
这不是危言耸听。我有一次帮人做模拟面试，对方笔试题 AC 了，但代码里有个全局变量在多个函数里被复用来复用去。我问"这个变量为什么在第二个用例里会被重置"，他愣了半分钟，最后承认自己没想过。本质上，笔试已经从"机器判分"悄悄变成了"机器判分 + 人工评审"的双重评价体系。
4.2 最容易暴露基本功的三处细节
具体来说，这三处细节最容易被放大检视，也最容易拉开差距。
第一处是输入边界和异常输入。数组为空、只有一个元素、值域达到题目上限、数值相加可能溢出——这些 corner case 不是附加题，而是基本功。我见过不少人主流程写得很漂亮，但一个"if (arr == null || arr.length == 0)"都没有。笔试平台可能不会为这些 case 单独设计样例，但面试官复看时一眼就能看出来。
第二处是命名与函数拆分。变量叫 idx 没问题，但最好是 windowStart、kthValue、nextTime 这种带语义的名字。超过 20 行逻辑就往小函数里拆，比如 splitIntoChunks、isTaskReady。很多人觉得笔试时间紧，写得快就行，但"快"和"乱"从来不是一回事。
第三处是注释思路，而不是注释过程。不要写"// 这里遍历每个元素"，而要写"// 滑动窗口右边界每次右移一位，左边界用于在窗口不合法时收缩"。前者是流水账，后者是在展示你的思考链。面试官想从代码里看到的是你的思路，不是代码执行轨迹。
举个例子，同样是滑动窗口求最小覆盖子串，差劲的写法可能是：
def minWindow(self, s, t): # 初始化 need = {} for c in t: need[c] = need.get(c, 0) + 1 l = 0 r = 0 cnt = len(t) res = s + "a" while r < len(s): if s[r] in need: if need[s[r]] > 0: cnt -= 1 need[s[r]] -= 1 r += 1 while cnt == 0: if len(s[l:r]) < len(res): res = s[l:r] if s[l] in need: need[s[l]] += 1 if need[s[l]] > 0: cnt += 1 l += 1 return res if res != s + "a" else ""能AC，但变量名没有任何语义。换成下面的写法，面试观感完全不同：
def minWindow(self, s: str, t: str) -> str: # 用 need 记录目标串还缺多少个字符，缺的字符数量为 missing need = collections.Counter(t) missing = len(t) left = 0 res = "" min_len = float("inf") for right, ch in enumerate(s): # 右边界进入窗口，如果这个字符正好是需要的，missing 减少 if need[ch] > 0: missing -= 1 need[ch] -= 1 # 窗口已经覆盖目标串，尝试收缩左边界 while missing == 0: cur_len = right - left + 1 if cur_len < min_len: min_len = cur_len res = s[left:right + 1] # 左边界移出窗口，恢复 need 计数 need[s[left]] += 1 if need[s[left]] > 0: missing += 1 left += 1 return res核心逻辑一样，但读代码的人不需要来回跳跃去猜变量含义。这也是我一直强调的：你把笔试代码当成一段要交付的代码来写，而不是一份草稿。
4.3 把笔试代码当成"待评审代码"来写
我自己的习惯是，代码写完先不当场提交，而是从头到尾通读一遍，假装自己是面试官，然后问自己几个问题：为什么用哈希表不用有序列表？为什么边界用小于等于而不是小于？为什么先排序再二分而不是边遍历边二分？为什么这里可以不用考虑整数溢出？
每想明白一个"为什么"，就在对应位置加一行注释。这一步看似浪费时间，但它在帮你把隐式的思维过程显性化。面试官读你代码的时候，其实是在模拟和你对话。你注释里想清楚了，他就不需要反复猜，自然对你评价更高。
甚至可以说，这道题答对只拿了 60% 的分，剩余 40% 全在你代码里体现的工程素养。刷题刷久了的人最容易忽略这一点，但恰恰是这一点，决定了你和其他候选人之间的区分度。
5. 重新调整你的刷题与笔试策略
说完三个陷阱，最后讲怎么应对。我给你的不是"每天刷十道题"这种空洞鸡汤，而是一套可以立刻执行的策略。
5.1 把 LeetCode 当健身房，而不是题库
第一，每周参加周赛当模拟笔试。周赛的时间压力、题目未知性，和真实笔试非常接近。你不需要纠结排名，而是把它当成一次限时演练，练的是"如何在 90 分钟内分配精力"和"如何面对没见过的题不慌"。
第二，每道题尽量做多解。一道题 AC 了，再想想如果数据规模扩大十倍还能不能过？如果内存缩小十倍呢？热门 100 题里的题至少都值得做两遍以上，但每次做都要带着新约束去做，最好能在注释里写出两种解法的时间、空间对比。
第三，训练"一题三问"的习惯。看到一道题，不要只满足于会写，多问自己：如果场景换成实时流式数据怎么做？如果输入是分布式的怎么拆？如果返回值要求有序怎么办？这个过程就是在模拟"业务包装题"的命题思路。
5.2 笔试现场的时间分配与自测流程
以一场 90 分钟 3 道题的标准笔试为例，我的通用时间分配是这样的：
- 前 10 分钟：通读所有题，不写代码。快速判断每道题的类型（裸算法、业务包装、系统交互模拟），按自己熟悉的程度排个做题顺序。先做最有把握的题，把保底分拿到手。
- 每题先确认理解：把输入、输出、数据规模、时限要求写在注释开头，再动手。
- 每题用"暴力 + 优化"两步走：先确保一个能跑出正确结果的版本，再针对性能瓶颈优化。宁可优化没做完，也不能出现"主流程没写完"的情况。
- 最后留 5-8 分钟做全卷检查：检查变量命名，给核心函数补注释，跑几个边界 case（空输入、单元素、最大值）。
一定要逼自己在最后留出自查时间。很多人不是不会做，而是提前 20 分钟就写完，然后干等交卷，结果漏掉了最基础的边界处理。如果你能每次笔试都系统地走一遍这个流程，你的得分稳定性会明显提升。
5.3 长期来看，这个变化是好事
我知道这些变化让人焦虑，尤其是准备很久的人，突然发现自己刷的题"不顶用"。但换个角度看，大厂笔试越来越像真实工作，其实是在变相保护真正有代码功底的人。
我见过太多简历写得天花乱坠、一到现场就露馅的候选人；也见过一些基础扎实、平时写代码就注重规范和边界的年轻人，笔试反而稳稳当当。这类人不需要临时突击，他们平时写内部工具、写自动化脚本时养成的习惯，已经在给他们加分。笔试考的不再是"你刷了多少题"，而是"你能不能像工程师一样思考"，这对行业、对认真做事的人都是好事。
最后给你一个马上能用的小建议：今天刷题的时候，不必追求数量，挑一道你已经 AC 过的题，用"业务包装 + 硬约束 + 代码评审"三重标准重新做一遍。你会发现，同一道题，用面试官的眼光看，处处都是可以优化的细节。这样的训练做满两周，你会明显感觉到自己笔试时的状态不一样了。
