Python列表去重怎么做效率最高_Set集合与Dict.fromkeys性能对比

Python列表去重怎么做效率最高？Set集合与Dict.fromkeys性能对比

说到Python列表去重，你是不是也遇到过这样的纠结：方法那么多，到底哪个又快又好用？今天咱们就来掰开揉碎了聊聊，看看在不同场景下，究竟该怎么选。

用 list(set(...)) 去重最简但不保序，适合纯去重场景

这恐怕是很多人学Python时记住的第一个去重“咒语”。直接把列表扔进set()，再转回list，干净利落。底层靠的是哈希表，时间复杂度O(n)，效率没得说。

但这里有个关键细节常被忽略：顺序没了。Python 3.7以后的字典确实能保持插入顺序，但set本身可是无序的。所以list(set([1, 2, 2, 3]))返回的可能是[1, 3, 2]，顺序完全看心情。

• 什么时候用它？当你只关心元素是不是唯一，压根不在乎它们原来怎么排的时候。比如统计一堆标签里有哪些不重复的，或者校验用户输入有没有重复项。
• 要注意什么？它处理不了字典、列表这类不可哈希的对象，硬来会直接抛给你一个TypeError: unhashable type: 'list'。

list(dict.fromkeys(...)) 是保序去重的默认推荐方案

如果你既想要去重，又不想打乱原来的顺序，那这个方法现在几乎是首选。它巧妙地利用了Python 3.7+字典保持插入顺序的特性：dict.fromkeys()会创建一个键唯一、值全是None的字典，然后我们再把它的键拿出来变成列表。

这样一来，既达到了去重的目的，又完美保留了元素第一次出现的顺序。性能上和set方案非常接近，可以说是目前最平衡的选择。

• 看个例子就明白：list(dict.fromkeys([3, 1, 2, 2, 1, 4])) 稳稳地返回 [3, 1, 2, 4]。
• 它的能力边界：和set一样，它能处理所有可哈希的类型，但面对嵌套的列表或字典同样无能为力。
• 性能怎么样？比手写循环快得多，毕竟是C层实现的。虽然内存上比set多存了一堆None值，但在实际应用中，这点开销几乎可以忽略不计。

遇到不可哈希对象（如字典列表）只能手动遍历 + in 或 seen 集合

现实项目里，麻烦往往从这里开始。当你的列表里装着字典或者别的列表时，上面两种“神器”就都失效了。这时候只能老老实实自己遍历判断，但“怎么判断”这个细节，直接决定了代码是流畅运行还是卡成幻灯片。

• 千万别这么干：有人会写[x for i, x in enumerate(lst) if x not in lst[:i]]。看起来挺聪明，但每次in操作都是O(n)，整个算法就成了O(n²)，数据量一大立马卡死。
• 正确的思路是：准备一个seen = set()集合，用来记录已经遇到过的可哈希标识。比如对于字典，可以用tuple(sorted(d.items()))把它转成一个元组；对于嵌套列表，如果内容允许，可以用json.dumps(x, sort_keys=True)转换成字符串作为标识。
• 简单情况怎么处理？如果结构不复杂且数据量不大，直接用json.dumps(x)当key最省事。不过得留个心眼，注意浮点数精度、NaN值这些边界情况。

别盲目迷信“最快”，先看数据规模和去重依据

追求极致性能没错，但得先搞清楚前提。在只有几百几千条数据的时候，纠结微秒级的差异真的没什么意义。真正影响你选择的是下面这几个问题：你需要保持顺序吗？你的元素能被哈希吗？你说的“重复”，是指完全一模一样，还是指某个字段（比如‘id’）相同就行？

这里有几个实用的判断原则：

• 数据量在万级以下：dict.fromkeys和手动写seen集合的差别可能连1毫秒都不到，这时候选哪个？当然选那个读起来更清晰、更容易理解的。
• 需要按字段去重（比如按字典里的‘id’）：那没别的办法，只能老老实实用循环，配合seen.add(item[“id”])。这种情况下，set和dict.fromkeys都派不上用场。
• 重复率特别高（比如日志里95%都是重复条目）：这时候，提前break或者用生成器避免一次性构建整个新列表，可能比选择哪种去重算法更重要。

说到底，在实际项目中，80%的去重需求，一个list(dict.fromkeys(...))就足够搞定了。剩下那20%让人头疼的情况，往往卡在“怎么定义什么叫‘重复’”，而不是“哪个函数跑得更快”。

立即学习“Python免费学习笔记（深入）”；