昨晚一个做后端三年的朋友跟我抱怨LeetCode刷了200多道但面试碰到爱吃香蕉的狒狒这种题还是卡了半天。我说问题不在你刷得太少而在你刷题的方式像吃快餐——做完就忘甚至没消化过。这个场景太典型了。我自己刷LeetCode三年多从一窍不通到能稳定参加周赛中间踩过的坑不比任何人少。这篇我想借几个大家特别熟悉的关键词——热门100题、题解、周赛430再加上我印象最深的一道经典题爱吃香蕉的狒狒来聊清楚一个问题怎么刷题才能让每一道题的功夫都不白费。无论你是刚开始准备笔试面试的新人还是刷到半途卡住的进阶者这套思路应该都能直接用。1. 刷题规划为什么热身要认准热门100题1.1 乱刷的代价先说说乱刷是什么状态。三年前我刚开始准备算法面试时每天打开LeetCode首页看哪道题顺眼就做哪道。简单题平稳过关中等题卡壳卡了半小时就翻题解把题解代码复制进来跑通标记已完成。一个月后我粗略统计做了六十多道但面试时被问到一个快慢指针的问题居然在纸上推导了半天才写对。这种状态的根源在于没有用题目之间的关系去组织知识。LeetCode题库现在有三千多道题每道都刷不现实也没有必要。真正刷一套够用的题量核心不是数量而是是否覆盖了算法面试会碰到的主要模式——数组、链表、哈希表、树、图、动态规划、二分搜索、滑动窗口、回溯、贪心以及它们的组合形态。1.2 热门100题为什么值得信任LeetCode热门100题是社区提交记录里出现频率最高的一百道题。它的价值不在于排名靠前而在于它是一组经过真实面试环境反复打磨过的模式样本——每道题通常对应一个算法结构中最典型的那个变体。做会100题相当于把二三十种核心模式都过了一遍并且每种模式还附带了三四个变体案例。再补一个个人经验热门100题不是刷一遍就算完。我的做法是基础轮按数据结构专题刷一遍记录每道题对应什么模式冲刺轮按题号顺序再刷一遍这一遍只看题目描述先回忆解法再看是否和标准解法一致。两轮下来题量还是100但记忆深度完全不同。1.3 一个可落地的刷题节奏我给不少人推荐过这套节奏管用第一轮专题数组/字符串 → 哈希表 → 链表 → 树 → 二分 → 动态规划 → 图每类10到15题。第二轮随机每天做两道一道简单题热身一道中等题主攻。面试前两周只刷目标公司面试频率榜前50配合周赛检验临场状态。这个节奏最大的好处是你在每道题里都能看到同类题目的骨架而不是在三千道题里原地打转。但100题只是范围不是护身符。真正拉开差距的是拿到一道没见过的题能不能自己推出来。这一点我强烈建议用875这道题来练。2. 875题实例读题到确定二分答案的完整推理2.1 先看题面到底在说什么LeetCode 875官方英文名叫Koko Eating Bananas中文站一般叫爱吃香蕉的狒狒有些第三方榜单里也写成073指的是同一道题。题面是有N堆香蕉第i堆有piles[i]根狒狒每小时会选择一堆吃掉k根如果这一堆剩余不足k根它会把这一堆全部吃完并且这一小时内不会再去吃别的堆。警卫会在h小时后回来问能满足条件的最小每小时速度k是多少。看到这题第一时间不要急着写代码先提取三样东西数据范围piles的长度最大10^4每堆数量最大10^9h最大也能到10^9级别。单调性k越大每小时消化能力越强吃完总时长越短k越小总时长越长。这是一个明显的单调关系。目标找最小的k使得吃完所有香蕉的总时间 h。这三样提取完成二分答案基本已经写在脸上了。如果k从1枚举到最大堆香蕉数复杂度是O(max(piles) * N)在10^9级别的数据下肯定挂。但利用单调性做二分搜索每次只判断一个mid是否可行总复杂度是O(N log(maxPile))几十万次运算完全能跑。2.2 为什么是二分而不是别的刚开始我的第一反应是直接算出总香蕉数除以小时数向上取整不就行了仔细一想不对因为吃每堆的时间是向上取整的和总量平均速度不是一回事。举例piles [3, 6, 7, 11]h 8。总香蕉数是27平均每小时3.375根看起来答案像是4。验证一下k 4时ceil(3/4) ceil(6/4) ceil(7/4) ceil(11/4) 1 2 2 3 8刚好及格。k 3时呢1 2 3 4 10超时。所以答案确实落在某个边界上但这个边界必须靠二分搜索精确找出来而不是靠平均值估算。这正是二分答案的标准场景给定一个可行性判定条件在一个单调区间内找最值点。2.3 判定函数与取整细节判定函数是这道题的核心单独抽出来写清楚bool canFinish(vectorint piles, int k, long long h) { long long total 0; for (int p : piles) { total (p k - 1) / k; // 等价于 ceil(p / k) } return total h; }这里有个细节值得敲黑板计算ceil(p / k)时不要用(int)ceil(p / (double)k)浮点运算在大数下容易踩精度坑。用整数技巧(p k - 1) / k又快又稳。另外total必须用long long单堆时间不大但10000堆加起来可能超过int上限。2.4 二分主流程int minEatingSpeed(vectorint piles, int h) { long long left 1, right *max_element(piles.begin(), piles.end()); while (left right) { long long mid left (right - left) / 2; if (canFinish(piles, mid, h)) { right mid; } else { left mid 1; } } return left; }注意left从1开始因为速度为0没有意义right从最大堆开始因为k大于等于最大堆数量时每堆一小时一定吃完总时间就是堆数N任何h N都能满足所以答案不会超过max(piles)。return left即可因为循环结束时left和right重合就是最小可行速度。2.5 一个容易忽略的边界如果h恰好等于N——也就是只有N小时——那么狒狒每小时必须恰好吃掉一整堆此时最小速度就是max(piles)。这个边界在二分中会自然收敛到右端点。我见过有人在测试用例[1, 2, 3, 4]h 4时疑惑为什么答案是4原因就是当速度不够大时某一小时会处理不完一堆只有当k max(pile)时总时间才等于堆数。这种边界靠背答案理解不了得在推理里自己推导一遍。3. 二分边界的痛所有二分题都卡在这几个地方3.1 闭区间还是左闭右开875题用的区间写法是闭区间[left, right]收敛条件是left right。很多人会混淆搜索空间里的left/right和答案的取值范围导致死循环或漏解。我给自己定了一条规则如果答案一定落在区间内用闭区间最后返回left如果你更习惯左闭右开就把right初始化为max(piles) 1返回时直接返回left。两种写法都能通过但必须固定一种当成习惯不要在题与题之间反复横跳。频繁切换是最容易写错死循环的根源。3.2 死循环的典型场景二分里最常见的死循环出现在left mid和right mid同时存在时且当left 1 right时mid会等于left区间永远无法缩小。我在875题这种找最小可行速度的题目里习惯用left mid 1配合right mid就能避免这个局面。如果题解区有人写left mid通常他需要在计算mid时加上一个1也就是mid (left right 1) / 2这两个写法是配套的。不要只抄一半。3.3 整数溢出和习惯养成虽然875这道题的右端点只有10^9left加上right不至于溢出long long但不要养出坏习惯——mid (left right) / 2在left right超过int上限时会溢出正确姿势是写成left (right - left) / 2。这个细节很小但在搜索插入位置、寻找峰值等热门题里同样成立。3.4 判定条件取整的翻车现场再强调一次(p k - 1) / k是用整数运算求向上取整的标准写法取整错误是这个题最容易拿WA的点。如果你把总时间算成了total p / k那么得出的结论会偏小从而错误地认为较慢的速度也满足要求——这在二分里意味着你会搜到一个过小的答案。我在实测中踩过一次类似的坑把p / k当成每堆耗时结果在piles [30, 11, 23, 4, 20]h 5时输出了4实际答案是30。原因就在于向上取整会显著增加每堆的时间而向下取整会让人误以为每堆都可以被切开快速完成——这是完全错误的物理直觉。4. 题解的正确用法把看懂的题解变成自己的判断力4.1 先承认一个事实看题解会上瘾我发现最影响刷题效率的习惯就是过早打开题解。刷题时遇到难题卡住三十分钟第一反应往往是看一眼题解思路就行结果开着题解把代码敲了一遍还告诉自己我掌握了。第二天重新做这道题还是卡在同一个地方。所以我给自己设了规则一道题至少独立尝试三十分钟三十分钟后如果还卡着允许看题解但只看题解中的思路描述部分看完思路后关掉页面自己把代码写出来。这个过程保证了理解发生在自己脑子里而不是在阅读别人代码的过眼云烟里。4.2 875题题解真正的核心信息875的题解会告诉你用二分答案做。这没有错但二分答案这个词本身信息量太低。有价值的题解会把问题转化为是否存在一个速度k使吃完所有香蕉的时间不超过h也就是说把最值问题套进一个单调判定函数里。这个转化才是本题的题眼。我在刷题笔记里把这种转化写成一句话模板题目问最小值且满足越大越容易/越小越容易的单调性 → 二分答案构造一个check(x)函数表示当参数为x时条件是否成立二分搜索x的取值空间。4.3 题解区里值得重点看的三个部分看875题的题解时我建议只看三类内容讨论为什么right取max(piles)而不是更大值的评论——这涉及搜索空间设计讨论取整方式的评论——这是精度与时间估算的核心对比不同语言实现的评论——理解判定函数在Java、Python、C里如何表达避免语言特性干扰算法理解。我不建议收藏整段代码更建议收藏逻辑骨架——比如把canFinish抽象成伪代码标注每堆耗时ceil(p/k)这比背代码有用得多。4.4 从875题发散出去的同类题875题真正练到的东西是二分答案这个大类。我把它跟下面的题放在同一组里复习LeetCode 1011在D天内送达包裹的能力——同样问最小的运载能力LeetCode 1482制作m束花所需的最少天数——问最小天数LeetCode 2064分配给商店的最多商品的最小值——同样是最大值最小化的结构LeetCode 2226每个小孩最多能分到多少糖果——判断函数换了一种表达方式。把这些题放在一起做一遍你会发现875教会你的不是狒狒吃香蕉而是把可行性判定函数写干净再套二分这个通用能力。5. 周赛430每周一次的实战是检验学习成果的最好方式5.1 为什么建议参加周赛周赛是目前为数不多能在限时、有压力、必须独立完成的环境下检验算法能力的场景。两小时做四道题节奏和面试非常接近。我参加过很多场周赛最后发现周赛表现和面试表现高度相关——不是说名次重要而是你的短板会在周赛里暴露得非常具体。以周赛430那一批题目为例它延续了周赛一贯的设计逻辑前两题覆盖最基础的思路转换和编码能力第三题要求在一个小时左右完成中等偏上难度的推理第四题是压轴题通常考较深的算法结构或者两个知识点的组合。如果你能稳定在30分钟内搞定前两题说明读题和基础功比较稳如果第三题总是卡在一个边界条件那说明练习时缺少对极端案例的自觉审视。5.2 周赛复盘比参赛本身更重要很多人的周赛体验是比赛时手忙脚乱结束后看题解感叹原来这么简单然后下一场继续。这样打一百场周赛也没用。我的复盘流程是比赛结束后不要立即看题解先尝试补题哪怕多花半小时对每道题记录卡在哪一步——是不会转换边界没想清楚还是代码实现出错统计一周内所有卡住类型的频率下周练习时优先针对最高频的那个短板。按照这个流程周赛才会变成以考促学的引擎而不是每周一次的焦虑来源。5.3 为什么875这类二分题在周赛里频繁出现周赛的中高难度题经常是二分答案 一个额外限制的变体因为这种题既能考察数学建模能力又能考察编码功底。875题就是典型主考点是二分答案隐藏考点是取整、数据范围和边界设定。你要是能把875吃透周赛里遇到最小××使得××的表述时第一反应不是慌张地枚举而是顺手画出单调关系然后写判定函数——这个思路拉开的差距比多记几个模板大得多。6. 把100题刷成十个模式而不是刷成一堆碎片6.1 模式归纳的价值热门100题不是为了让你把一百个答案背下来而是让一百个具体问题变成你脑中十个左右抽象模式的载体。拿我自己举例刷完875之后我再看到任何最小速度、最少天数、最大装载量一类的问题第一件事都是问自己随着参数变大可行性是否单调变化如果是直接进入二分答案流程。这种思考方式的转变才是刷题刷透的标志。6.2 如何做模式归纳我给自己定的规则是每做完三道同类题就写一张模式卡。卡片内容包括题型特征、判定函数模板、边界案例、同类题列表。不需要多精美关键是表达出这类题我怎么识别它。以二分答案为例我的模式卡写的是特征问最小/最大的某个量使得某种条件成立判定函数把条件成立写成布尔函数边界搜索空间从1到最大可能值求最小值就用leftmid1求最大值就用rightmid-1。6.3 一点个人体会如果你现在刚开始刷LeetCode我建议不要贪多每天两道题但每道题都要走完整个流程——先自己思考半小时再看题解确认最后做同类题巩固。这个流程初期会慢但一个月后你会发现遇到新题时不再是两眼一抹黑而是能一层层把题目的结构剥开。875这道题是我刷题路上印象很深的一块跳板。希望这篇聊完你能从一道具体的题里拿到整个二分答案大类的钥匙。