Python mode 的并列规则：票数完全相同，为什么换个输入顺序就换了结果
整理一组错误标签时，蓝色与红色出现次数相同。把输入按另一种顺序读取后，mode突然换了答案，容易让人怀疑计数不稳定。实际上它已经执行了一个确定的并列规则：在频次最高的值中，返回最先遇到的那个。输入顺序因而成为结果的一部分。
本例在Linux、CPython 3.12.14实跑，无第三方依赖。保存为demo.py，运行python3 demo.py。两份短列表拥有完全相同的成员与次数，只交换首次出现的位置；后半段再分别测试拒绝并列、按字典序裁决和空列表，所有数据仅保留在内存。
AI模型生成概念插图：两列等高筹码保持并列，箭头只标出先遇到的一列；不是统计工具界面。
完整程序与本地结果
完整可运行程序
from statistics import mode, multimode, StatisticsError
first = ["blue", "red", "red", "blue", "green"]
second = ["red", "blue", "red", "blue", "green"]
assert sorted(first) == sorted(second)
assert mode(first) == "blue"
assert mode(second) == "red"
print("first order:", mode(first), multimode(first))
print("second order:", mode(second), multimode(second))
def choose_unique(values):
winners = multimode(values)
if len(winners) != 1:
raise ValueError("a unique mode is required")
return winners[0]
try:
choose_unique(first)
except ValueError:
print("tie policy: rejected")
else:
raise AssertionError("the tie must be visible")
chosen = min(multimode(first))
assert chosen == "blue"
print("lexical tie policy:", chosen)
assert choose_unique(["red", "blue", "red"]) == "red"
assert multimode([]) == []
print("empty multimode:", multimode([]))
try:
mode([])
except StatisticsError:
print("empty mode: StatisticsError")
else:
raise AssertionError("empty input must fail")本次实际输出（以下为结果，不是程序）
first order: blue ['blue', 'red'] second order: red ['red', 'blue'] tie policy: rejected lexical tie policy: blue empty multimode: [] empty mode: StatisticsError
频次相同，先遇到的值取得单个出口
first order返回blue，second order返回red。程序先断言两个列表排序后完全相等，所以差异不能归因于漏算或多算。变化来自首遇顺序：mode需要给出一个值，而当前规则没有要求在并列时抛出异常。
multimode则分别给出两个顺序不同的列表，成员都是blue和red。它保留所有最高频值，并按首次出现排列；输出列表的先后不是票数高低，因为它们已经同票。若页面把第一项画成唯一冠军，仍然是展示层额外作出的选择。
让业务明确选择怎样处理并列
choose_unique检查候选数量，只有恰好一个时才返回。并列会触发ValueError，空输入也会触发同一个应用错误。这里适合“只有唯一常见值才能自动填充”的导入任务，调用方可以把失败送入人工核对队列，而不是默默采用文件顺序。
另一种规则是min(multimode(first))，本例得到blue。这使相同计数集合在重排后仍选同一标签，但成立前提是业务接受字典序作为裁决，且候选能够互相比较。它并没有证明blue更合理；更常见的做法是提供显式优先级表，并检查所有候选都在表中。
空输入与没有唯一众数要分别验收
multimode空列表返回空列表，mode空列表抛StatisticsError。不能直接把min套在任意multimode结果外面，因为空候选又会使min失败。示例展示字典序分支时已使用已知非空数据；正式函数应先决定无数据究竟返回缺失状态还是报错。
对于每个值都只出现一次的数据，所有值都并列最高频。若把“最常见”理解成明显占多数，还需要检查出现次数、总样本量和占比门槛。众数只是频率比较，不自动提供多数保证，也不能替代样本是否覆盖真实情况的判断。
把顺序来源写进交付约定
读取多个文件、拼接分页或并发收集结果时，首遇顺序可能来自调度与合并方式。若业务依赖mode的首遇规则，应先建立稳定输入顺序；若业务只关心计数集合，应显式处理并列，不要让一次重排变成隐藏的产品决定。
本例使用可哈希的普通字符串，避开了混合数字类型、NaN和自定义相等比较的额外语义。实际分类汇总先统一标签规范，再做计数；回归样本至少包含唯一最高频、并列最高频、全不重复和空输入，才能证明应用出口完整。
把最小复现接到真实排查
一个常见场景是根据最近几条记录补全缺失分类。先把已知分类交给统计函数，再区分没有样本、唯一最高频与并列三种出口，才能避免把“读取顺序碰巧靠前”伪装成足够明确的依据。若业务要求至少两次支持，还应在返回之前单独检查次数。
也可以将全部并列候选随报告一起交付，让下游明确决定。此时最好同时保存候选频次与总记录数，因为只有两个名称无法看出它们是各出现一次，还是各出现一千次。候选清单用于保留歧义，后续动作仍需依据自身规则处理。
测试时不要只重排一对相邻元素。可以把同一计数集合分别安排成红色开头、蓝色开头和第三种低频标签开头，观察最高频候选的首次出现关系。低频值先到不应成为赢家，这能区分真正的并列规则与错误地直接取列表首项。
版本也是复现条件之一：较老的Python曾对多众数抛出异常，当前文档记录了规则改变。维护旧脚本时，应按部署版本核对既有异常处理是否还会执行。本文结果固定在已注明版本，不把历史行为与当前行为混在一套验收条件里。
参考资料
资料核验日期：2026年10月2日。以上输出来自固定输入的本地实跑，程序退出码为0。
