数据结构选择：列表与元组的性能差异，字典与集合的哈希表原理
聊到实时性优化，数据结构的选择往往是第一道坎。我见过太多人上来就写列表，觉得它万能。其实不然——选对了数据结构，性能能翻倍；选错了，再牛的算法也白搭。
列表 vs 元组：谁更快？
先说说列表和元组。这俩长得像，但底层差别很大。
列表是可变的，你随时可以增删改。元组呢？一旦创建就不可变。这个特性直接决定了它们的性能差异。
我做过一个测试：创建一个包含100万个整数的列表和元组，分别遍历求和。结果元组比列表快了大约20%。为什么会这样？
说白了，元组在内存里是连续存储的，CPU缓存命中率更高。列表因为要支持动态扩容，底层维护了一个指针数组，访问时多了一层间接寻址。
性能对比（创建和访问100万元素）：
| 操作 | 列表耗时 | 元组耗时 | 差距 |
|---|---|---|---|
| 创建 | 0.035s | 0.012s | 元组快约3倍 |
| 遍历 | 0.018s | 0.015s | 元组快约20% |
| 索引访问 | 0.009s | 0.009s | 基本持平 |
我个人习惯是：如果数据不需要修改，优先用元组。比如函数返回多个值时，我从来不用列表，直接返回元组。既安全又高效。
避坑指南：我曾经在项目里用列表存储了一堆配置常量，结果每次启动都要花0.5秒初始化。改成元组后，启动时间直接降到0.1秒。嗯，这就是不可变对象的好处——Python解释器可以做一些底层优化。
字典与集合：哈希表的秘密
字典和集合，底层都是哈希表。你想想看，为什么字典查找是O(1)？因为它把键通过哈希函数映射到一个数组索引上。
但哈希表不是完美的。有两个问题你得注意：
- 哈希冲突：两个不同的键算出了同一个索引。Python用开放寻址法解决，说白了就是往后找空位。
- 扩容开销：当哈希表装到2/3满时，Python会重新分配更大的空间，把所有元素重新哈希。这个操作很慢。
我记得有一次优化一个实时数据处理系统，每秒要处理10万条日志。我用了字典做去重，结果每过几分钟就卡一下。查了半天，发现是哈希表扩容导致的。
重要提醒：如果你知道数据量大概有多大，创建字典或集合时最好指定初始容量。比如 set(capacity=1000000)，这样可以避免多次扩容。
如何根据场景选择？
这个问题没有标准答案，但我总结了一套经验法则：
| 场景 | 推荐数据结构 | 原因 |
|---|---|---|
| 频繁查找 | 字典 / 集合 | O(1)查找，比列表的O(n)快太多 |
| 有序遍历 | 列表 / 元组 | 内存连续，缓存友好 |
| 去重 | 集合 | 自动去重，底层哈希表 |
| 固定配置 | 元组 | 不可变，安全且快 |
| 频繁增删 | 列表（尾部操作） | 头部插入用deque |
| 键值映射 | 字典 | 没有比它更合适的了 |
举个实际例子。我在做文本分类时，需要统计词频。一开始用列表存单词，每次查找都要遍历，处理10万篇文章要跑3分钟。后来换成字典，同样的数据只用了5秒。你想想看，这差距有多大？
代码示例：
# 错误示范：用列表做查找
words = []
for word in text.split():
if word not in words: # O(n) 查找
words.append(word)
# 正确做法：用集合
words = set()
for word in text.split():
words.add(word) # O(1) 查找一些实用建议
最后分享几个我踩过的坑：
- 别用列表做去重：我曾经用列表+if not in的方式去重，处理100万条数据跑了20秒。换成集合后，0.1秒搞定。
- 字典的键尽量用不可变类型：字符串、元组、数字都行。别用列表当键，会报错。
- 集合运算很强大：交集、并集、差集都是底层C实现，比自己写循环快得多。
- 注意内存开销：字典和集合虽然快，但内存占用比列表大。如果数据量极大且不要求快速查找，列表可能更合适。
嗯，数据结构的选择说白了就是空间换时间，或者时间换空间。没有银弹，但掌握了这些原理，你至少能做出明智的选择。