lee.2m这道题我在面试中问过别人，也在被面试时被问过，还见过不少人在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榜单里遇到同类问题时会顺畅很多。
哈希集合方案本身只有十几行代码，但真正值钱的不是那十几行，而是背后那个“从起点开始扩展”的思维模型。你以后遇到任何“从一组元素中找出满足某种连续或相邻关系的最大集合”这类问题时，都可以尝试问自己一句：什么才是起点？有没有办法让每个节点只被处理一次？一旦想清楚这两个问题，很多难题会瞬间变得清晰起来。