摩尔投票法详解：O(n)时间O(1)空间找出多数元素

1. 一次算法面试，让我重新认识了“投票”

几年前我面一家做实时推荐系统的公司，技术面到最后，面试官问了一道看似平平无奇的题：“给你一个长度为 n 的数组，找出其中出现次数大于 n/2 的元素，要求时间复杂度 O(n)、空间复杂度 O(1)。”

我第一反应是哈希表计数——遍历一遍，Map 里存次数，最后扫一遍找最大值。时间复杂度 O(n) 没问题，但空间复杂度是 O(n)，不满足要求。排序取中间值也行，但排序就是 O(n log n)，超了。当时我卡了很久，最后面试官提示了一句：“你可以试试把数组里两个不同的数同时删掉，想想剩下什么。”

这正是**摩尔投票法（Boyer-Moore Voting Algorithm）**的核心思想。它由 Robert S. Boyer 和 J Strother Moore 于 1980 年提出，最初用于在流式数据中高效寻找多数元素，后来成为算法面试中的经典考点。虽然叫“投票”，但它和民主投票没什么关系，更像是一种“抵消”策略：两个不同的人打架，互相抵消，最后站着的一定是人数占优的那一方。

如果你正在准备算法面试、刷 LeetCode，或者工作中遇到“找主元素”“找高频项”之类的需求，这篇文章值得你认真读完。我会从最直观的直觉讲起，把正确性证明、代码细节、常见变形、容易踩的坑一次说透。

2. 核心思想：为什么“互相抵消”能找出多数元素

2.1 从一个极简例子理解抵消

先看一个具体例子。假设数组是：

code复制[7, 7, 5, 7, 5, 1, 7]

7 出现了 4 次，长度是 7，4 > 7/2，所以 7 是多数元素。

现在模拟抵消的过程：从第一个元素开始，拿 7 当候选人，票数记为 1。遇到的第二个元素还是 7，票数加 1 变成 2。第三个元素是 5，和当前候选人不同，票数减 1 变回 1。第四个元素是 7，票数加 1 变 2。第五个元素是 5，不同，票数减 1 变 1。第六个元素是 1，不同，票数减 1 变 0。票数归零意味着候选人被完全抵消了，于是把下一个元素 7 设为新候选人，票数为 1。遍历结束，候选人是 7。

这个过程看起来简单，但背后隐藏了一个关键的数学事实：如果一个元素出现次数超过 n/2，那么任意成对删去两个不同的元素，这个元素依然是剩余部分的多数元素。 因为多数元素比其他所有元素的总数还要多，所以每次“一换一”地抵消，最后留下的必然是它。

2.2 和“配对删除”的等价性

用生活化的类比来理解：假设一个房间里有 n 个人，每个人支持一个阵营。多数阵营的人数超过一半。如果每次从房间里揪出两个支持不同阵营的人，让他们同时离开房间，反复操作，会发生什么？

• 如果多数阵营的人被揪出来，那和他配对的一定是少数阵营的人，所以一次操作多数阵营只减少 1 人。
• 如果多数阵营的人没被揪出来，那少数阵营内部互相消耗，多数阵营人数完全不变。

无论哪种情况，多数阵营始终比其他任何单一阵营的人数多。当房间里只剩下一个阵营的人时，那个阵营必然是最初的多数阵营。这个结论非常强，它意味着抵消顺序不影响最终结果——只要多数元素存在，任意抵消策略最后剩下的都是它。

2.3 关键前置条件：多数元素必须存在

这里必须强调一个容易忽略的前提：摩尔投票法的经典版本假设多数元素一定存在。 如果数组中不存在出现次数超过 n/2 的元素，算法最后留下的候选人可能是任意值，必须再做一次遍历统计它的真实出现次数来验证。

比如数组：

code复制[1, 2, 3, 4, 5]

模拟投票过程，最后留下的候选人是 5，但 5 只出现了 1 次，不是多数元素。所以流程必须是：先跑投票，得到候选人，再扫一遍确认。LeetCode 169 题明确说了“你可以假设数组是非空的，并且给定的数组总是存在多数元素”，所以很多题解省去了验证步骤，但实际工程中你绝不能省。

3. 手写实现与正确性证明

3.1 从零推导代码结构

摩尔投票法的实现极其简洁，核心只需要两个变量：

• candidate：当前候选人
• count：当前候选人的净票数（支持数减反对数）

遍历数组时只有两种情况：count 为 0，说明当前没有有效候选人，直接把当前元素设为候选人，count = 1；count 不为 0，就比较当前元素和候选人是否相同，相同则 count++，不同则 count--。

写成代码：

cpp复制int majorityElement(vector<int>& nums) {
    int candidate = 0;
    int count = 0;
    for (int num : nums) {
        if (count == 0) {
            candidate = num;
            count = 1;
        } else if (num == candidate) {
            count++;
        } else {
            count--;
        }
    }
    return candidate;
}

另一种写法是 count == 0 时直接 candidate = num，然后统一走后面的逻辑，不用先给 count 赋 1，代码会更紧凑，但上面的写法更直白，不容易绕晕。我个人推荐初学者用第一种。

Python 版本同样简洁：

python复制def majority_element(nums):
    candidate = None
    count = 0
    for num in nums:
        if count == 0:
            candidate = num
        count += 1 if num == candidate else -1
    return candidate

3.2 正确性的数学证明

直觉懂了还不够，面试时你最好能给出严谨证明。这里提供两种思路，一种偏反证法，一种偏归纳法。

反证法思路： 假设算法结束时候选人 c 不是多数元素，但真实多数元素是 m。由于 m 出现次数大于 n/2，而其他所有元素出现次数总和小于 n/2。每一次 m 和别的元素抵消时，m 的“票数”净变化是 -1；而当 m 和 m 相遇时，m 的票数净变化是 +1。既然 m 的总出现次数占优，那么无论抵消策略如何，把数组按“扫到的元素是否等于候选人”分成两类，m 的净票数始终为正。另一方面，如果算法结束时候选人不是 m，说明 m 的票数在某一段被完全抵消归零了，这和一个总数占优的元素不可能被完全抵消矛盾。

这个表述有点绕，我更推荐下面这种更直观的证明。

配对抵消证明： 把数组从左到右扫描，每当 count 归零时，就把“当前这一整段”切出来，从扫描起点到当前位置。这一段里，第一个元素是这段的候选人，并且在这段中它的出现次数恰好是这一段长度的一半（否则不会正好归零）。因此，这一段中不存在任何“出现次数超过段长一半”的元素。把这段整个扔掉，对剩余部分来说，如果整个数组存在多数元素 m，那么 m 在剩余部分依然是多数元素——因为被扔掉的部分至多“帮” m 抵消了同等数量的非 m 元素，整体优势只会保持或扩大。重复这个操作，直到遍历完整个数组，最后剩下的那一段中，候选人就是唯一的可能多数元素。

这个证明最清晰，也最接近摩尔投票法设计者的原始意图。

3.3 复杂度：为什么它是 O(1) 空间

摩尔投票法最厉害的地方在于空间复杂度。哈希表法需要存储元素和频次，空间开销和数据规模线性相关；排序法如果允许原地排序，空间是 O(1)，但时间变慢。而摩尔投票法从头到尾只用两个变量，不记录任何历史频次信息，只维护一个“净胜票数”。这相当于把庞大的频次表压缩成了单个标量，因为“多数元素”本身就是一个全局性约束极强的性质——只要存在多数元素，你不需要知道每个元素的完整频次，只需要知道谁能在两两抵消中胜出。

这带来一个工程上的好处：它可以处理流式数据。 如果数据是一个无限序列，你不可能用哈希表存下所有频次，但摩尔投票法可以一边读一边更新，任何时候都只需要 O(1) 空间来维护当前候选人。这个特性在实时日志分析、在线投票统计中非常实用。

4. 代码实战：从裸题到变形题

4.1 LeetCode 169：多数元素

这是最基础的题目。题目保证多数元素存在，所以直接返回候选人即可：

cpp复制class Solution {
public:
    int majorityElement(vector<int>& nums) {
        int candidate = 0, count = 0;
        for (int num : nums) {
            if (count == 0) {
                candidate = num;
            }
            count += (num == candidate) ? 1 : -1;
        }
        return candidate;
    }
};

这类题一定要写熟，能做到闭着眼睛写出来。我面试别人的时候发现，很多人能背出代码，但问两句“为什么 count 归零要换候选人”就卡壳。代码只占这道题价值的 30%，剩下的 70% 在理解和表达。

4.2 LeetCode 229：求众数 II（超过 n/3）

题目升级：找出数组中所有出现次数超过 n/3 的元素。结论是这样的元素最多有 2 个，因为如果超过 3 个，总数就超过 n 了。

思路是把“两两抵消”升级成“三三抵消”：维护两个候选人和两份票数。遇到新元素时，先看看能不能匹配候选人 A 或 B，能则对应票数加 1；如果两个候选人的票数都大于 0 但都不匹配，说明出现了三个不同阵营的人，让这两个候选人的票数同时减 1；如果某个候选人的票数为 0，则用当前元素替换这个候选人。

代码实现：

cpp复制vector<int> majorityElementII(vector<int>& nums) {
    int candidate1 = 0, candidate2 = 0;
    int count1 = 0, count2 = 0;
    for (int num : nums) {
        if (num == candidate1) {
            count1++;
        } else if (num == candidate2) {
            count2++;
        } else if (count1 == 0) {
            candidate1 = num;
            count1 = 1;
        } else if (count2 == 0) {
            candidate2 = num;
            count2 = 1;
        } else {
            count1--;
            count2--;
        }
    }
    // 验证阶段
    vector<int> result;
    int n = nums.size();
    if (count1 > 0) {
        int c1 = 0;
        for (int num : nums) if (num == candidate1) c1++;
        if (c1 > n / 3) result.push_back(candidate1);
    }
    if (count2 > 0) {
        int c2 = 0;
        for (int num : nums) if (num == candidate2) c2++;
        if (c2 > n / 3) result.push_back(candidate2);
    }
    return result;

}

这里有个特别容易踩的坑：在验证阶段，candidate1 和 candidate2 可能相同。 比如数组全是同一个元素 [2,2,2,2]，第一个候选人被 2 占据后，因为始终匹配，count1 一直增加，candidate2 始终没机会替换。但由于 num == candidate1 时直接走第一个分支，candidate2 不会被赋值，所以两个候选人不会相同。但如果在某些分支顺序的写法下，可能出现同一个元素占据两个候选位的情况，验证时会重复添加。稳妥的做法是验证时做一个去重判断：

cpp复制if (candidate1 != candidate2) {
    // 各自统计并添加
} else {
    // 只统计一次
}

4.3 面试进阶：摩尔投票法的本质是“寻找多数”而非“统计频次”

很多人刷题刷多了会形成一种惯性——看到“出现次数超过一半”就条件反射想到摩尔投票法，但如果题目换成“寻找出现次数最多的元素”呢？这时候摩尔投票法就不适用了。它寻找的不是“最多”，而是“超过某个比例阈值”的元素。要分清楚：哈希表适合精确统计，摩尔投票法适合在线判断是否存在“绝对多数”。 面试时如果能把适用范围说清楚，会显得理解远高于背题的人。

比如一个常见面试变形：数据流中不断有数据到达，如何实时找出当前是否有多数元素？用摩尔投票法可以做到：维护 candidate 和 count，每来一个元素更新一次，然后判断 count > 0 且该元素的真实频次超过总数一半。但注意，count > 0 不等于该元素就是多数元素，最终仍需全局验证，因为数据流是动态的，前半段成立的多数元素可能在后半段被推翻。但摩尔投票法的价值在于：你不需要重新扫描整个流，只需要 O(1) 状态就能维护一个“最有可能的候选人”。

5. 复杂度与思路选型：何时选摩尔投票法

5.1 和经典方案的对比

面试时，很多人第一个想到的是哈希表，这没毛病，但我们需要了解不同方案的差别。下表整理了常见方案的对比：

从表格能看出，摩尔投票法在“找绝对多数”这个问题上几乎是最优的。它在时间上是一次遍历，空间上是常数——这两个约束同时满足的方案其实非常少。排序和哈希表都各有短板，分治法虽然理论上也能做到 O(n log n)，但工程实现复杂，没人会用它写这道题。

5.2 实际工程中的取舍

在实际工程里，“找多数”这种需求并不像 LeetCode 上那么理想化。数据可能非常大，存在磁盘上；数据可能不断流入，没有固定长度；数据分布可能是倾斜的，也可能根本没有多数元素。我印象最深的一个场景是超大规模日志中提取“高频错误码”。

假设某个系统每天产生 10 亿条日志，每条日志对应一个错误码，你想找出当天出现次数超过 50% 的错误码——如果存在的话。这种场景下：

• 把所有日志读进内存做哈希表，内存直接爆炸；
• 排序，单机 10 亿条数据根本排不动；
• 摩尔投票法可以在流式读取日志时实时维护一个候选项，如果日志流中存在“绝对多数错误码”，它一定能找出来；
• 但因为日志流里的元素分布是未知的，你必须在找到候选后，再扫一遍日志统计真实频次确认，或者用分布式框架分批统计后汇总。

当然，真实场景中“某一种错误码占 50% 以上”是非常罕见的，更常见的是“占比最高的 top 10”。这种需求就要用 Count-Min Sketch 之类的概率数据结构了。摩尔投票法适合少数但需求极度精确的场景。

5.3 为什么“验证”这一步永远不能省

代码实现了，例子也跑通了，但我要强调：在你的实际代码里，验证这一步绝不能省。 LeetCode 的题目会告诉你保证存在多数元素，但真实世界的输入不会跟你保证任何事。

如果不验证，可能出现下面这种情况：

code复制输入: [1, 2, 3]
模拟投票: 1 被 2 抵消，2 被 3 抵消，候选人是 3

但 3 在数组中只出现了 1 次，根本不是多数元素。如果你直接返回 3，轻则算错结果，重则在生产环境产生 bug。正确做法是：首先找出候选人，然后遍历数组统计候选人出现次数，确定是否真的超过 n/2，不满足就返回一个特殊值或抛出异常。

5.4 真实需求中还要考虑分布式扩展

如果是分布式环境，数据分散在多台机器上，每台机器都能独立跑一遍摩尔投票法，但合并各机器的结果并不那么简单——不能直接比较各机器的 candidate 就得出全局结论，因为每台机器只看到了数据的一部分。

这时可以在每台机器上统计出候选人的局部出现次数，然后汇总到一台机器做二次统计，或者干脆在分布式框架里用两阶段聚合：第一阶段各节点各自跑投票法，第二阶段把各节点的候选人和“净票数”发到中心节点合并。但说实话，工程上更常用的还是先做精确分组计数，因为引入分布式之后，摩尔投票法的常数级空间优势被通信开销摊薄了，实用性不如“每个 key 单独计数后合并排序”来得直接。

6. 我踩过的坑与调优笔记

6.1 警惕“票数归零”的边界条件

我第一次写摩尔投票法时，在边界条件上栽过跟头——我的代码长这样：

cpp复制for (int num : nums) {
    if (count == 0) {
        candidate = num;
    }
    if (num == candidate) {
        count++;
    } else {
        count--;
    }
}

这个代码在 count == 0 且 num == candidate 时其实有问题：新候选人已经换成了 num，所以 num == candidate 恒为真，count 直接变成 1。看起来没问题，但假如 count 刚好为 0，而当前元素选为候选人后，下面又走了一次 num == candidate 的比较，语义上是自增，逻辑也正确。当时真正的问题出在哪里呢？问题出在我把两个 if 写成了独立分支，但实际上换了候选人之后，num == candidate 一定成立，count 先被置 1 然后又加 1，变成 2。

所以代码写完后，我习惯用一个极端用例测试——全部元素相同、没有多数元素、只有一个元素——这三个用例每个都必须跑通。

6.2 相同候选人的“覆盖”问题

在写 LeetCode 229 求众数 II 时，我遇到过一个隐蔽的 bug：候选人有两席，但某一时刻可以用同一个数字占两席。我当时写的更新逻辑是先检查是否匹配候选人，再检查空位：

cpp复制if (count1 == 0) candidate1 = num;
else if (count2 == 0) candidate2 = num;

这个顺序在特定输入下会导致候选 1 和候选 2 变成同一个数字。出现这种情况并不是最终的返回结果一定错——反正验证阶段会过滤——但如果两个候选人相同，后面减票的逻辑就会变得混乱，净票数可能算错。正确写法是：先匹配已有的候选人，再考虑替换空位，并且替换前确认 num 不等于另一个候选人。

6.3 真实调试中的几个反直觉案例

调试摩尔投票法有一个很反直觉的地方：你看代码根本看不出问题，因为错误只发生在特定的抵消序列中。 我建议打印每一步的 candidate 和 count 变化，配合纸笔手推，比干瞪眼快得多。

举个例子，[1, 3, 1, 1, 2] 这个数组，正确输出是 1。手推一下：

最终 candidate = 1，count = 1，验证 1 出现 3 次，是多数。但如果加一个元素让数组变成 [1, 3, 1, 1, 2, 2]，手推到最后 candidate 仍然是 1，count 为 0，此时你不能说 1 是多数元素——因为根本没有多数元素。这类用例帮我养成了一个习惯：输出候选人不等于输出答案，count 大于 0 也不等于验证通过。

6.4 当题目限制被放宽时怎么“偷懒”

有一些情况下，摩尔投票法实现可以更紧凑。比如 Go 语言：

go复制func majorityElement(nums []int) int {
    candidate, count := 0, 0
    for _, num := range nums {
        if count == 0 {
            candidate = num
        }
        if num == candidate {
            count++
        } else {
            count--
        }
    }
    return candidate
}

注意这个版本里，当 count == 0 时，candidate = num 后一定会进入 num == candidate 分支让 count 变成 1，语义是正确的。但如果你把第二个 if 改成 else if，那当 count == 0 时 count 会保持 0，下一轮循环又重置候选人——这就有 bug 了。不同语言的同款逻辑略有差异，不要无脑套模板。

7. 从一道题到一个算法思想：我的学习心得

刷算法题很容易陷入“背题”的误区，但摩尔投票法是我觉得“顿悟感”最强烈的一个算法之一。它的实现代码短到不像话，但背后“成对抵消、多数必胜”的思想，却可以推广到很多场景。

比如你可以把“找超过 n/2”推广到“找超过 n/3”“找超过 n/k”，都可以用维护 k-1 个候选人的通用模板。面试时如果能写出通用解法，会比只背两道题给面试官留下更深的印象。

我个人的体会是，接触一个新算法时要问自己三个问题：

1. 它解决什么问题？（找超过固定比例的候选元素）
2. 它利用了目标元素的什么性质？（多数元素数量超过所有其他元素之和）
3. 如果目标条件不满足，算法会发生什么？（候选人可能是任意值，需要二次验证）

想通了这三点，你才算真正掌握了摩尔投票法，而不仅仅是会背代码。

最后再分享一个小技巧：如果你在面试中遇到这个题，即使面试官没有要求 O(1) 空间，也可以从哈希表方案讲起，然后顺着“空间能否优化”逐步引入摩尔投票法，把暴力解、哈希表、排序、摩尔投票法的思路完整地讲一遍。这不仅能体现你的思维层次，也能让面试官看到你不是死记硬背，而是真正理解每一种方案的取舍。这也是我后来面试候选人时最看重的点。