预分配容量不能消除哈希冲突，关键在控制负载因子；dict.fromkeys() 比 {} 逐个插入快因一次性预估大小避免多次扩容重哈希；键的哈希值需分散且与 eq 一致，避免退化为 O(n)；字符串前缀相似易致局部聚集，应优化键设计而非硬调。
预分配容量能显著缓解哈希冲突导致的性能下降，但不能消除冲突本身；真正起作用的是控制负载因子，而非“避免冲突”。
为什么 dict.fromkeys() 比 {} 逐个插入快得多
逐个插入时，Python 在每次 dict[key] = value 后检查负载因子，一旦超过 2/3 就触发扩容——这意味着对 10 万个键，可能经历多次翻倍重建（如 8 → 16 → 32 → 64 → 128k），每次都要重哈希全部已有键；而 dict.fromkeys(keys) 会一次性按 len(keys) 预估底层数组大小（通常向上取整到最近的 2 的幂，并预留足够空槽），跳过中间所有扩容步骤。
- 实测：11 万字符串键，
{}循环赋值耗时约 320ms；dict.fromkeys(keys)仅需 95ms - 注意：
dict.fromkeys(keys, default)中default是**同一个对象引用**，别传可变对象（如[]） - 若键是动态生成、无法提前枚举，可用
dict.__new__()+dict.update()组合模拟预分配（不推荐，仅限极端场景）
自定义类作键时 __hash__ 实现不当会直接退化为 O(n)
CPython 不校验你写的 __hash__ 是否合理，但它直接影响探测长度。若返回常量（如 return 1），所有实例哈希后都落在同一槽位，字典退化为线性查找链表。
- 正确做法：哈希值应尽量分散，且与
__eq__一致。例如：def __hash__(self): return hash((self.id, self.name)) - 危险操作：在对象生命周期中修改影响
__hash__的属性（如obj.id = new_id），会导致原键“消失”——查不到，删不掉 - 调试技巧：用
hash(obj)打印几个实例的哈希值，看是否集中（如全为偶数或全模 8 余 1）
字符串键前缀相似时冲突概率陡增，这不是 bug 是设计使然
CPython 的字符串哈希算法对连续字符敏感，"user_0001" 和 "user_0002" 的哈希值往往高位相同，取模后易落入相邻槽位，形成局部聚集——探测序列被迫“绕远路”，平均查找步数上升。
立即学习“Python免费学习笔记（深入）”；
- 临时缓解：给键加随机扰动，如
f"{key}_{random.randint(0, 999)}"（仅测试用，破坏语义） - 长期方案：改用更散列的键，比如把
"user_0001"替换为uuid.uuid4().hex[:8]或 base62 编码的递增 ID - 不要试图重写
str.__hash__——它被硬编码在 C 层，且受PYTHONHASHSEED影响，跨进程不一致
哈希冲突本身不可消除，关键在让探测路径短、扩容次数少、键分布散；预分配和键设计比调优代码逻辑更能立竿见影——但一旦键的哈希值天然聚集，再大的初始容量也救不了探测延迟。
