查元素快不快主要看是否使用哈希表：dict和set平均O(1)，list/tuple最坏O(n)；哈希冲突严重时性能退化至接近O(n)；用set替代list判断成员可显著提速。
查元素快不快，主要看用不用得上哈希表
Python 的 dict 和 set 底层是哈希表，平均情况下查元素是 O(1)；list 和 tuple 是数组实现，查元素得遍历，最坏 O(n)。别被“平均”骗了——如果大量插入导致哈希冲突严重（比如往 dict 里塞一堆结构相似的自定义对象且没重写 __hash__），实际性能可能退化到接近 O(n)。
常见错误现象：if x in my_list: 在循环里反复调用，数据量一过千就明显卡顿；换成 my_set = set(my_list); if x in my_set: 立刻变快。
- 用
set存查找目标（去重+快查），哪怕只查几次也值得转一次 -
dict查 key 快，但查 value 仍是O(n)—— 没捷径，别幻想dict.values()自带索引 - 小数据量（list 反而比
set更轻量，别机械套“哈希一定快”
要改数据还是只读，决定了能不能用 tuple
tuple 不可变，内存更紧凑、创建更快、能当 dict 的 key；list 可变，支持增删改。但“不可变”是浅层的——如果 tuple 里存了 list，那个 list 还是可以改的，只是你不能替换整个位置。
使用场景：tuple 适合做配置项、函数返回多值（a, b = func() 实际返回的就是 tuple）、字典键（如 cache[(x, y)] = result）；list 适合需要 .append()、.pop() 或按索引改值的地方。
立即学习“Python免费学习笔记（深入）”；
- 别为了“看起来不可变”硬把
list转成tuple，结果里面嵌了个可变对象，徒增理解成本 -
tuple作为函数参数传入后，接收方无法通过类型判断它是否真该被当常量用——靠文档和命名约定，不是靠语法 - 用
typing.NamedTuple或dataclass(frozen=True)比裸tuple更明确表达“这是结构化只读数据”
删元素时 list.pop(i) 和 set.remove(x) 的代价差很远
list.pop(i) 删除中间元素要移动后面所有项，平均 O(n)；set.remove(x) 是哈希定位后直接断链，平均 O(1)。但注意：set 不保证顺序，也不能按位置删（没有下标概念）。
错误现象：用 for i in range(len(my_list)): 遍历时边查边 my_list.pop(i)，结果漏删、索引错乱；或者想用 set 去重后还要保持原顺序，却直接转回 list(set(...)) 导致顺序全乱。
- 要删多个指定值且关心顺序？先建
set存待删项，再用列表推导式：[x for x in my_list if x not in to_remove_set] - 要按位置批量删（如删索引 2~5）？
list切片赋值更稳：del my_list[2:6] -
set.discard(x)比remove(x)安全——没找到也不报错，适合不确定元素是否存在的场景
内存占用差异在大数据量时会暴露得很真实
同数量级整数：tuple list dict ≈ set。因为 dict/set 要预留哈希桶空间（初始至少 8 个槽，即使只存 1 个元素），且每个元素额外存哈希值和指针。而 tuple 和 list 就是连续指针数组。
实测：存一百万个整数，list 约占 36MB，tuple 约 28MB，set 约 45MB（含空桶）。如果你在内存敏感环境（如嵌入式 Python、Lambda 函数）处理几十万条数据，这个差距会让 OOM 来得更早。
- 只读且需索引访问？优先
tuple，别图省事用list - 用
sys.getsizeof()测内存前，记得它不统计内部对象（比如list里的字符串），只算容器本身开销 -
array.array('i', ...)比list[int]省得多——但失去通用性，只存数字时才考虑
list 看似慢却最灵活，set 查得快却丢顺序，tuple 省内存但改不了，dict 键快值慢——选哪个，得看你代码里**真正瓶颈在哪一行**，而不是凭印象猜。 
