x in list是O(n)线性遍历，x in set是O(1)哈希查找；100万数据查1000次，list耗时约11.8秒，set仅约0.002秒，快5500倍；极小数据（1–2元）list或略快，但实际场景中set为存在性检查唯一合理选择。
in 操作的底层机制完全不同
用 x in list 时，Python 必须从头到尾逐个比对，遇到匹配就停——最坏情况要扫完整个列表，时间复杂度是 O(n)。而 x in set 本质是哈希查找：先算 x 的哈希值，直接定位桶位置，平均只需一次内存访问，时间复杂度是 O(1)。
这不是“语法糖优化”，而是数据结构层面的差异。list 是连续数组，set 是哈希表（实际复用 dict 的底层，只是不存 value）。哪怕只查一次，差距也来自“要不要遍历”这个根本动作。
实测性能差距有多大
在 100 万整数的容器中查 1000 次随机值：
-
list耗时约 11.8 秒 -
set耗时约 0.002 秒
也就是快 **5500 倍**。换成字符串或更大数据量，差距只会更大。注意：这还不是最差情况——如果目标值总在列表末尾，list 实际耗时会线性增长；而 set 几乎不受影响。
立即学习“Python免费学习笔记（深入）”；
什么情况下 set 不一定更快
极小数据量（比如只有 1–2 个元素）时，list 可能略快，因为哈希计算本身有固定开销。但这种场景没实际意义：你不会为两个元素专门做 in 判断。
真正容易踩的坑是：
- 反复在循环里写
if x in some_list—— 应该提前转成some_set = set(some_list)复用 - 误以为
set适合索引访问（s[0]会报错），它不支持下标，也没顺序概念 - 往
set里塞不可哈希对象（如list、dict），会直接抛TypeError
别被构造时间误导
有人测过 set(range(10000)) 比 list(range(10000)) 慢一点，就怀疑 set 整体不快——这是典型误解。构造是一次性成本，而 in 是高频操作。只要你要查 3 次以上，set 的总耗时就反超了。
真正关键的是使用模式：如果你需要多次判断“是否存在”，set 是唯一合理选择；如果只是遍历或按序取值，list 更自然。两者不是替代关系，而是分工明确。
