这道题我在面试中问过别人,也在被面试时被问过,还见过不少人在O(n)这个要求上栽跟头。LeetCode 128题“最长连续序列”看起来只是“找出数组中最长连续数字的长度”,但它其实是哈希表、去重思想和边界条件的集合体。尤其是题目明确要求时间复杂度O(n)时,很多人第一反应写排序,然后发现过不了,最后只能在评论区看别人的思路。这篇文章我会从题目怎么理解开始,把你需要掌握的所有解法、实现细节、坑点以及面试应对思路全部讲透,直接按照实战标准来。
1. 题目解读:先读懂再动手
1.1 题目到底在问什么
力扣128题给的描述很简洁:给你一个未排序的整数数组,要求找出数字连续的最长序列的长度,并且要求时间复杂度是O(n)。这里有几个关键点一定要抠清楚。
“未排序”这三个字意味着你不能指望数组本身有序,所有有序信息都需要自己构建或者另辟蹊径。然后是“数字连续”这几个字,注意不是等差连续,也不是在原数组位置上相邻,而是值本身大小连在一起。换句话说,数组里出现了3和4,不管它们在数组里的位置隔了多远,它们都算连续的。
举个例子,数组[100, 4, 200, 1, 3, 2],这里最长连续序列是1、2、3、4,长度是4。虽然4和100离得很近,但100和99、101都没有出现在数组里,所以100只能自己作为长度1的序列存在。这个例子是题目自带的,也是理解这道题的关键钥匙。
还有一个隐蔽信息:题目说的是“序列”,不是你平常见到的“连续子数组”,也不是“连续子串”。所以元素不需要在原数组里挨着。这种设定直接决定了不能用滑动窗口之类的子数组技巧来处理,必须换思路。
我建议读完题先别急着敲代码,先在纸上把题目的输入输出关系画一遍,搞清楚“连续”到底怎么判定。很多时候不是算法不会,而是题目理解偏了,后面全跑偏。
1.2 跟着样例走一遍
题目给的示例:[100, 4, 200, 1, 3, 2]。我们先看1,它左边是0不在数组里,右边是2在,然后3在,4在,5不在,所以从1开始的序列是1、2、3、4,长度为4。再看2,它左边1在,所以就算从2开始也不行,因为2前面有数,它最多只是1后面的一部分。同理3、4也一样,都是大序列里的节点。
看100的时候,左边99不存在,右边101不存在,所以它自己长度为1。200同理,也是孤立点长度1。所以答案取最大值4。整个判断过程的核心就是“这个数是否是一个序列的起点”。
什么叫序列起点?就是x-1不在数组里,而x在数组里。换句话说,只有它没有前驱时,它才有可能开启一段全新的连续序列。只要x-1在数组里,说明x一定是从更早的某个数延续过来的,如果以它为起点去数,只会数出一段此前已经被覆盖过的序列,白白浪费时间。
这个“判断起点”的思想是整个哈希集合解法的灵魂。普通解法不管三七二十一,每个元素都往外扩展找邻居,复杂度瞬间变成O(n^2),数据一大直接爆炸。先判断起点,再扩展,这样能保证数组中每个元素最多被某个起点路过一次,总代价压到O(n)。
理解“只有x-1不在数组中时才能作为起点”,是这道题从O(n^2)进化到O(n)的分水岭。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 解法演进:排序不是最优解
2.1 最先想到的排序做法
很多拿到这道题的人第一反应是排序。也确实,排序后连续数字会聚在一起,只要遍历一遍数连续递增的个数就能得到答案。思路大致是这样的:先对数组排个序,然后从第二个元素开始逐个扫描,如果当前数字等于前一个数字加1,就把当前连续长度加1;如果相等,说明有重复元素,跳过继续;否则说明断了,更新答案并重置长度。
针对题目给的示例[100, 4, 200, 1, 3, 2],排序后变成[1, 2, 3, 4, 100, 200]。遍历时1到4正好连续,长度累到4,到了100发现和前一个4差了一大截,更新答案为4,再从100重新计数。最后结果是4,跟预期一致。
这个方案很好写,代码在三四分钟内就能完成,而且不容易出错。如果面试时时间紧张或者题目没有O(n)的硬性要求,排序做法绝对是性价比最高的保底方案。
但问题在于力扣128题明确写了“时间复杂度O(n)”。这句话把所有比较排序的路子都堵死了,因为基于比较的排序,理论上限是O(n log n)。你用Arrays.sort、Collections.sort还是手写快排,都绕不开这个复杂度。即使你用计数排序、基数排序这类非比较排序,在处理整数范围极大或负数存在时也要付出极高的空间代价,甚至无法应对输入范围超过几亿的情况。
所以在LeetCode上运行排序法,会直接收到超时或不符合题目要求的反馈。面试时面试官看你写排序法,大概率会让你继续优化,这时候就说不出“不会”之类的话了。我自己就见过有候选人排序写得很顺,但一问到“能不能O(n)”瞬间卡壳,就很可惜。
2.2 为什么排序法不符合O(n)要求
一句话解释:找连续序列,本质上是在无序数组里做集合关系的查询,而排序法把力气花在了把所有元素的大小关系完全排列清楚上,这远远超出了找连续序列所需的信息量。
这就像你只需要知道邻居家有没有养狗,结果把整个小区所有住户的信息按字母表排了一遍。确实能查到邻居的信息,但中间大量排序工作其实是多余开销。
一般排序算法基于元素两两比较大小来确定位置。n个元素判断大小顺序至少需要O(n log n)次比较,这是信息论层面的下界。而找最长连续序列这件事,理论上只需要判断“某个数是否存在”和“某个数的前驱是否存在”,这样的判断可以通过哈希表以O(1)的代价完成。既然能用O(n)的代价解决问题,就不该付O(n log n)的额外成本。
这里顺便区分一个概念:排序后数组确实有序,所以查找元素时可以二分O(log n),但这里的问题限制在O(n),说明题目想要的是利用哈希表实现的近似线性时间算法,而不是基于有序性的搜索。很多人一看到“数组”两个字就本能地想排序,这是一种思维定式,需要通过这道题刻意识别并打破。
2.3 空间换时间是核心思路
既然要O(n)时间,我们可以在空间上放开手脚,用O(n)的哈希表来换时间。哈希表的查找、插入、删除平均都是O(1),这正好是我们需要的。
把数组所有数字放入哈希集合后,我们只需要对每个可能的序列起点进行扩展。关键点是每个数字只会被访问常数次。具体来说,外层循环遍历数组中的每个数字,但内层循环只会在遇到“起点”时触发扩展,而且扩展过程中走过的那些数字,后续再作为外层元素时不会再次扩展,因为它们在集合中已经被访问标记,或者它们本身因为有前驱而不符合起点条件。
这种“空间还时间”的策略在算法里很常见,比如两数之和用哈希表替代双重循环,LRU缓存用哈希表加链表实现O(1)访问。力扣128题又是一个典型示例,你需要体会的是:当时间上的要求非常严苛,而空间不设限时,哈希表通常是最直接的武器。
3. 哈希集合解法:题目的标准答案
3.1 一个关键前提:去重
进入哈希集合解法前,必须先处理重复元素问题。假设数组是[1, 2, 2, 3],如果不做去重,直接按原始元素逐个判断,可能会出现重复计数或者误判起点的情况。虽然去重后再处理会绕开这个问题,但底层逻辑要清楚。
把数组放入Set集合时,重复元素会被自动移除。比如[1, 2, 2, 3]送去Set只剩下{1, 2, 3}。对连续序列的查找来说,重复元素没有任何作用,因为序列只关心值的连续性,不关心值出现了几次。如果一个数字在数组中出现多次,它的重复副本既不能扩展序列长度,也不会产生新的序列方向,完全多余。
不少人的做法是不去重,直接遍历原数组,但因为Set查询时会去除重复,所以即使原数组有重复也没有影响。不过有个细节值得注意:如果你用数组原始数据跑循环,Set里没有重复,每个值只会触发一次起点判断,实际上逻辑上已经自动完成了去重。你完全可以外层遍历原数组,只要判断都在Set上进行即可,不受重复元素干扰。
为了逻辑更严谨,我写代码时习惯先把所有元素放入Set,然后只遍历Set里的元素,避免无意义的重复访问。在数据量大的情况下,这种写法也能削减外层循环的迭代次数,尽管最坏情况复杂度一样,但实际跑起来更快。
3.2 优化的核心:只从序列起点开始
哈希集合解法的核心就是“只从起点开始”。假设我们在Set中碰到一个数字x,如果x-1也在Set中,那么x不可能是某个连续序列的最左边界,因为序列的前一个数字已经出现了。即便我们对x进行扩展,得到的序列也必然是从x-1或者更早的数字开始的那条序列的子集,必然不是最优解,所以可以直接跳过x。
反过来,如果x-1不在Set中,x就是一个可能的序列起点。此时使用currentNum记录从x开始的连续数字,初始为x,用currentStreak记录长度,初始为1。只要Set中存在currentNum + 1,就循环递增currentNum并同步增加currentStreak,直到数字断开。当循环结束时,用当前得到的currentStreak更新全局最长长度。
这个起点判断的精妙之处在于:它使内层循环不会重复处理已经属于某个更长序列的数字。你可以这样理解,整个数组中,只有序列的第一个数字才有资格发起向后扩展,其他的数字都只是“既得序列”的一部分。所以所有数字中,序列起点最多只有若干个,每个起点扫描的长度刚好对应它所在序列的长度,把整条序列的长度与起点数相乘,总体扫描量还是O(n)。
3.3 复杂度分析:为什么是O(n)
很多刚学这个算法的人会疑惑,外层循环遍历数组每个数,内层while循环又可能扫过很多数,这不就成O(n^2)了吗?
关键点在于:内层while循环并不是对每个外层元素都会完整执行。只有满足“x-1不在Set中”即x是起点的元素,才会进入while循环,而且一旦进入,它会沿着当前连续序列一直向后遍历。这个序列中的所有元素,在后续的外层循环中都会因为x-1在Set中,而被直接跳过,不会再进入新的while循环。
换句话说,每个数字最多被访问两次:一次是外层判断它的前驱是否存在,另一次是作为某个起点序列的后续元素,在while循环中被访问。总的访问次数是O(n),所以总时间复杂度是O(n)。空间复杂度方面,Set存储了所有元素,也是O(n)。
这个均摊思想比较重要,类似KMP算法中next数组的构建,虽然看起来有循环嵌套,但每个位置最多被回溯固定次数,总代价是线性的。如果你面试时讲不清楚这里为什么是O(n),面试官会怀疑你对复杂度的理解还停留在套模板阶段。
3.4 代码实现与逐行注释
以Java为例,最直接的实现方式如下:
java复制class Solution {
public int longestConsecutive(int[] nums) {
// 用Set存储所有数字,同时完成去重
Set<Integer> numSet = new HashSet<>();
for (int num : nums) {
numSet.add(num);
}
int longestStreak = 0;
// 遍历Set中的每个数字,而不是原始数组,避免重复元素干扰
for (int num : numSet) {
// 只有当前数字没有前驱时,才可能是序列起点
if (!numSet.contains(num - 1)) {
int currentNum = num;
int currentStreak = 1;
// 不断往后扩展连续序列
while (numSet.contains(currentNum + 1)) {
currentNum += 1;
currentStreak += 1;
}
// 更新全局最大值
longestStreak = Math.max(longestStreak, currentStreak);
}
}
return longestStreak;
}
}
这段代码每一次循环都有它的目的。首先,建立哈希集合时如果原数组是空数组,Set为空,longestStreak保持0,符合预期。其次,for循环遍历Set而不是nums,这个细节虽然看起来不起眼,但在有大量重复元素的输入里能省不少无用功。
Python版本代码会更简洁:
python复制class Solution:
def longestConsecutive(self, nums: List[int]) -> int:
num_set = set(nums)
longest = 0
for num in num_set:
if num - 1 not in num_set:
current_num = num
current_len = 1
while current_num + 1 in num_set:
current_num += 1
current_len += 1
longest = max(longest, current_len)
return longest
Python的set由哈希表实现,in操作平均O(1)。把nums转成set这一步本身就要O(n)时间,所以整体复杂度依然是O(n)。Go语言的实现思路完全一样,这里不重复贴代码,关键数据结构是map[int]struct{}。
还有一点很值得注意:检查条件用的是num-1而不是num+1。如果你写反了,变成从每个元素向后探测后一个元素,那就等于每个元素都可能是起点,会导致重复计数,复杂度退化为O(n^2)。判断起点必须是检查前驱是否存在,这是算法正确性的前提。
4. 边角情况与常见坑
4.1 重复元素会误导你
很多第一次做这道题的人,遇到重复元素时会出现误判。比如数组是[0, 0, 1, 2, 3],如果你不考虑去重而用某种直观的计数方式,可能得到长度3,这没问题。但如果你拿原数组遍历,用某种滑动逻辑数连续个数,就可能在0出现两次时错误地把0算成两个连续位置,得到长度4的错误答案。
重复元素问题的核心是:题目要求的是“值连续”的最大长度,而不是“元素出现次数叠加”后的长度。同一个值出现了两次,并不能让连续序列的长度乘2。比如数组[1, 1, 1, 1, 1, 2, 3],最长连续序列长度是3,不是7。如果把每个元素都当成独立个体来计数,会把重复的1也算进去,导致错误。
使用Set去重是最干净的解法。如果你写排序版本,排序后也要跳过重复元素,否则重复数字会干扰连续计数。排序法里处理重复是目前最容易出bug的点——比如if-else的顺序没安排好,把重复数字误判成序列断裂,结果得到错误的最大值。
4.2 负数、0、空数组
数组里可能有负数和0,比如[-3, -2, -1, 0, 1],最长连续序列长度是5。Set方案天然支持负数,因为判断逻辑只关注数值本身,不涉及数组下标,所以负数和0都没有任何特殊处理成本。
空数组的情况直接返回0,因为没有任何元素,就没有任何连续序列。单元素数组,比如[5],返回1,因为只有一个数字,它自己就是长度1的序列。
另外还有全是重复值的数组,比如[0, 0, 0],去重后只有{0},最长长度1。如果不小心在排序解法里没有跳过重复元素,可能算出3,这就错了。所以无论用哪种方案,重复值处理都是一道基础关。
这里有组测试用例你可以直接拿去验证自己的代码:
- nums = [],期望0
- nums = [1],期望1
- nums = [1, 2, 0, 1],期望3(0、1、2连续)
- nums = [0, 3, 7, 2, 5, 8, 4, 6, 0, 1],期望9(0到8连续,再加9不在所以是9)
- nums = [100, 4, 200, 1, 3, 2],期望4
如果这些用例全部通过,你的代码基本没有方向性问题了。
4.3 一亿个元素的极端情况
当你处理的数据量接近千万甚至上亿级别时,哈希集合方案依然能用,但要留意内存。Java的HashSet
实际工程中如果遇到“给几亿个ID找最长连续段”这类需求,不建议直接把所有数据一次性加载到内存。可以采用外部排序加分段扫描的方式,或者采用分治思路:先按范围分桶,对每个桶内做连续序列统计,再处理桶与桶之间的接缝。面试时聊到这里已经超过题目本身的要求,但能体现你对大规模数据的处理意识,绝对是加分项。
至于LeetCode的评测数据,正常情况下也就几万个元素,用常规哈希集合跑完全没问题。真正要关注的其实是复杂度分析是否严谨,而不是评测机跑不跑得过。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 解决方法 |
|---|---|---|
| 结果比预期长 | 未处理重复元素,重复计数 | 使用Set去重或在排序后跳过重复 |
| 结果比预期短 | 起点判断条件写反,只从x+1不存在的位置开始 | 改为判断x-1是否在集合中 |
| 空数组返回null或异常 | 没有初始化longestStreak为0 | 初始值设为0,空集自然返回0 |
| 单元素数组返回0 | 循环逻辑少于一次遍历 | 检查返回前是否至少尝试计算currentStreak |
| 大数组运行超时 | 用了O(n^2)内层循环或错误排序 | 使用Set加起点判断的O(n)方案 |
| 负数结果不对 | 使用了数组下标标记元素值 | 改为哈希集合或Map结构 |
这个表在面试前扫一眼能帮你快速定位自己的代码问题。很多时候错不是算法错,而是细节没处理好,而这种题又恰恰喜欢考细节。
5. 进阶思路与面试现场
5.1 并查集方案的思路
除了哈希集合方案,并查集(Union-Find)也能解决这道题。思路大致是:每个数字初始单独成一个集合,当遍历到一个数字x时,如果x+1已经存在,就把x和x+1所在的集合合并;如果x-1已经存在,就把x-1所在的集合和x合并。合并时维护每个集合的大小,最终答案就是最大的集合大小。
这个方案的时间复杂度在加入路径压缩后接近O(n α(n)),其中α(n)是反阿克曼函数,非常接近常数。空间也是O(n)。虽然实现上比哈希集合方案复杂不少,但它能体现你对并查集数据结构的掌握程度,在面试里属于高级展示项。
不过要明确地讲,这道题用并查集属于“杀鸡用牛刀”,面试官一般不会期待这种解法,你用它做出来的效率也未必比哈希集合方案高。哈希集合方案写起来只需要几行,思路清晰,边界好处理,是标准答案。并查集的优势在于应对“动态添加数字并实时查询最长连续序列”这类变体,如果面试官追问“比如数据是流式到达的,怎么办”,这时候你引出并查集就有说服力了。
5.2 多种思路对比
| 解法 | 时间复杂度 | 空间复杂度 | 实现难度 | 适用场景 |
|---|---|---|---|---|
| 排序后扫描 | O(n log n) | O(1)或O(n) | 简单 | 无O(n)要求时快速实现 |
| 哈希集合 | O(n) | O(n) | 中等 | 题目标准解,静态数据最优 |
| 并查集 | O(n α(n)) | O(n) | 较复杂 | 动态添加数据、实时查最长段 |
| 字典动态规划 | O(n) | O(n) | 中等 | 便于扩展到统计区间端点 |
现在主流模式识别基本是这样的:拿到题目,如果没有时间限制就先写排序版本验证思路;面试官要求优化时再切到哈希集合版本,重点讲为什么复杂度能到O(n)。
5.3 面试官想考察什么
我在面试别人的时候,如果出这道题,我真正想听的并不是候选人能不能写出哈希集合解法,而是他在思考过程中的几个关键节点。
第一,他能不能识别出重复元素对连续序列统计的影响。很多人一上来就忽略重复值,代码跑几个用例就出错。这说明对题目条件的分析不细致,面试是减分项。
第二,他能不能从“找某个元素是否存在”这个需求联想到哈希表。如果候选人能说出“因为只需要O(1)查询某个数是否存在,所以我会用Set”这种话,说明他有基本的数据结构选型能力。
第三,他能不能把自己提出的O(n)解法解释清楚。最怕遇到的情况是候选人背了答案,代码写对了,但一问为什么内层循环总体是O(n)而不是O(n^2),就开始支支吾吾。如果你能主动画出几个边界用例,说明均摊逻辑,面试官基本会认可。
第四,他有没有主动考虑边界条件。比如空数组、只有一个元素、全重复元素,这些用例在代码里有没有覆盖。很多候选人写完代码直接说“好了”,根本不测边界用例,这种习惯在工程里容易出事。
所以面试时别急着写代码,先把思路说出来,再把复杂度分析讲清楚,边写边解释,这样面试官能轻松跟上你的思路,印象分会高不少。
5.4 扩展:遇到变体题怎么办
LeetCode很喜欢把一道经典题包装成各种变体。比如把“最长连续序列”改成“最长连续1的个数”,给定一个二进制数组,找最长连续1的数量。这种题本质上更简单,因为数组里只有0和1,且要求物理位置连续,直接用滑动窗口或者一次遍历就能搞定。
另一种变体是“最长连续递增序列”,这时候序列要求递增,同时位置也要连续,通常用动态规划一次遍历就能解决。而力扣128题里的“连续”不要求位置连续,所以才能这么做。你要分清楚“值连续不要求位置连续”和“位置连续值也要递增”之间的区别,这两类题解法完全不同。
如果把128题改成“数组是数据流,随时可以添加新数字,每次添加后要能快速返回当前最长连续序列长度”,那么哈希集合方案每次加入新数都可能导致多个序列段的合并,需要额外维护区间端点。这个变体其实就自然延伸到了“维护区间合并的Map”或者并查集。在面试时如果你能主动讨论这些扩展,会显得你对算法体系的理解是成网的而不是散点。
6. 从做题到应用:这个算法的实际价值
6.1 连续登录天数统计
题目本身是抽象的,但它的模型可以在业务中直接落地。比如很多互联网产品要做“用户最大连续登录天数”的统计,数据源是用户在某个时间段内的登录日期列表,很可能同一个用户在同一天有多次登录记录,需要先去重,再找最长的连续日期段。
如果把日期转换成自增的天数序号,那么“连续登录天数”就变成了“最长连续序列长度”。比如用户A登录了2024-01-01、2024-01-02、2024-01-05、2024-01-06、2024-01-07,转换成年初以来的第几天后,变成[1, 2, 5, 6, 7],最长的连续段是5、6、7,长度3。这正是128题直接套用的方式。
数据规模大的时候,比如几千万用户,每个用户的计算任务相互独立,可以用MapReduce或分布式分片把不同用户分到不同worker上计算。单机场景下用哈希集合就够,而且哈希集合在处理几万个登录日期时完全秒开,性能压力可以忽略。这能让你真正感受到LeetCode算法在业务场景中的价值。
6.2 需要O(n)的真实场景
为什么算法题要反复提到O(n),真实场景里又有什么需求是非线性不可的?答案就在数据规模上。假设你的服务每天有几千万次点击流日志,每条日志包含用户ID和时间戳,你想在内存里快速算出“今天最长的连续活跃用户段”,但数据量大到O(n log n)级别的排序就没法在毫秒级响应。
这时候哈希表方案的优势就很明显了,它能以接近线性的时间对每个用户ID做处理,内存占用依然保持在O(n)。实际业务中,可能需要你先按用户分组,然后对每个用户的日期集合跑哈希集合算法。为了减少开销,还可以用位图、布隆过滤器等工具预处理无效数据。
另一个方向是时序数据中的“连续缺失检测”,比如监控系统要判断某台机器的网络连接中断是否连续超过N分钟,并希望在采集到新数据时快速判断当前是否处于连续异常段。这种场景对实时性要求很高,O(n^2)直接就顶不住,而哈希集合加区间合并可以在O(1)均摊时间内完成状态更新。
LeetCode等刷题平台的题目虽然看起来是纯学术问题,但它的底层逻辑和复杂度模型跟真实在线系统高度同构。你在面试时说得出“这个模型可以用在监控系统连续故障检测中”,面试官通常会觉得你既有算法功底又有工程视野。
6.3 刷题方法论沉淀
最后说一点方法论层面的东西。力扣128这道题不是一个偏题怪题,它属于“看似简单其实有门槛”的类型。我刷题这些年体会到,面对这类题,有几个通用步骤特别管用。
第一步,先说暴力解。不管多笨,先把题目要求的结果算出来,哪怕是O(n^2)的穷举。这能帮你确认自己对题意的理解是否正确。第二步,找冗余。暴力解之所以慢,是因为它反复计算了大量不需要的信息,比如对每个元素都去扩展连续序列,但其实起点才能扩展。定位冗余就是优化的入口。第三步,换数据结构。如果瓶颈是查找,考虑哈希表;如果瓶颈是动态取最值,考虑堆;如果瓶颈是区间合并,考虑并查集。第四步,重新分析复杂度,确认是否达到要求。大部分题目经过这四步,即使你不能立刻写出最优解,也能在面试中展示出清晰的思考路径。
力扣128题我后来在好几家公司面试时都遇到过,甚至有一次是作为系统设计面试的热身题出现的。那个时候我才意识到,这道题不仅是一道算法题,更是一个考察候选人是否具备“识别数据特性并选择合适的抽象结构”能力的试金石。如果你能把这道题做透,理解它背后的哈希表选型、复杂度均摊分析和边界处理思路,那么你在力扣hot100榜单里遇到同类问题时会顺畅很多。
哈希集合方案本身只有十几行代码,但真正值钱的不是那十几行,而是背后那个“从起点开始扩展”的思维模型。你以后遇到任何“从一组元素中找出满足某种连续或相邻关系的最大集合”这类问题时,都可以尝试问自己一句:什么才是起点?有没有办法让每个节点只被处理一次?一旦想清楚这两个问题,很多难题会瞬间变得清晰起来。
