阿丁的猫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，或者工作中遇到“找主元素”“找高频项”之类的需求，这篇文章值得你认真读完。我会从最直观的直觉讲起，把正确性证明、代码细节、常见变形、容易踩的坑一次说透。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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) | O(n) | 需要精确频次、元素范围大 | 空间开销高，不适合数据流 |
| 排序后取中位数 | O(n log n) | O(1)（原地） | 实现最简单 | 排序改变了原数组（除非拷贝），时间较高 |
| 随机抽样验证 | 期望 O(n) | O(1) | 工程中不确定数据分布时 | 是概率算法，最坏情况可能反复失败 |
| 摩尔投票法 | O(n) | O(1) | 寻找超过 n/k 的候选元素 | 要求多数存在或需要二次验证；无法获取精确频次 |
| 分治法 | O(n log n) | O(log n) | 理论上可用 | 常数大，维护递归栈 |
从表格能看出，摩尔投票法在“找绝对多数”这个问题上几乎是最优的。它在时间上是一次遍历，空间上是常数——这两个约束同时满足的方案其实非常少。排序和哈希表都各有短板，分治法虽然理论上也能做到 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 | count |
|---|---|---|---|---|
| 初始 | - | - | - | 0 |
| 1 | 1 | count=0，设 1 为候选人 | 1 | 1 |
| 2 | 3 | 不同，抵消 | 1 | 0 |
| 3 | 1 | count=0，设 1 为候选人 | 1 | 1 |
| 4 | 1 | 相同，+1 | 1 | 2 |
| 5 | 2 | 不同，-1 | 1 | 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 个候选人的通用模板。面试时如果能写出通用解法，会比只背两道题给面试官留下更深的印象。
我个人的体会是，接触一个新算法时要问自己三个问题：
- 它解决什么问题？（找超过固定比例的候选元素）
- 它利用了目标元素的什么性质？（多数元素数量超过所有其他元素之和）
- 如果目标条件不满足，算法会发生什么？（候选人可能是任意值，需要二次验证）
想通了这三点，你才算真正掌握了摩尔投票法，而不仅仅是会背代码。
最后再分享一个小技巧：如果你在面试中遇到这个题，即使面试官没有要求 O(1) 空间，也可以从哈希表方案讲起，然后顺着“空间能否优化”逐步引入摩尔投票法，把暴力解、哈希表、排序、摩尔投票法的思路完整地讲一遍。这不仅能体现你的思维层次，也能让面试官看到你不是死记硬背，而是真正理解每一种方案的取舍。这也是我后来面试候选人时最看重的点。