大字典卡顿源于rehash：容量不足时需重新分配内存并迁移所有键值对，百万级键高频写入时单次耗时几十毫秒；可通过预设容量（如dict.fromkeys()、推导式或update批量插入）避免频繁扩容，而sys.setswitchinterval无效，因rehash全程持gil。
为什么大字典会突然卡住？
Python的dict在容量不足时会触发rehash：分配新内存、遍历所有键值对、重新计算哈希并插入新表。当字典有百万级键、且在高频写入中反复扩容时，单次rehash可能耗时几十毫秒——这对延迟敏感服务（如API响应、实时计算）就是明显的卡顿源。
这不是bug，是Cython实现的正常行为；但可以预判和规避。
用dict.fromkeys()或预设大小初始化
Python 3.9+ 支持dict.__init__()接收预估长度，但更可靠的是用dict.fromkeys()配合占位值，或直接用{}后立刻update()一批数据——这两种方式都会让底层哈希表按需一次性分配足够空间，避免早期小步扩容。
- 错误做法：
d = {}然后循环d[k] = v插入10万条 → 可能触发5–7次rehash - 推荐做法：
d = dict.fromkeys(keys, None)（若只需键存在），或d = {k: v for k, v in data}（推导式自动优化初始容量） - 极端场景可手动估算：
d = {}→d.update(large_iterable)，CPython会对update()中的可迭代对象做容量预估
sys.setswitchinterval()不能解决rehash卡顿
有人误以为调小GIL切换间隔能“切碎”rehash时间，实际无效：rehash是纯C操作，全程持有GIL，不会被中断。这个函数只影响线程调度点，对字典内部的内存重排毫无作用。
真正有效的控制手段只有两个：控制初始容量、减少动态增长频次。
- 避免在循环里反复
del d[k]再d[k] = v——这不节省内存，反而可能因删除后空洞积累，导致下次插入仍需rehash - 如果必须增量更新，考虑先累积变更（如用
list暂存(k, v)对），再批量update() - 监控字典实际使用率：
len(d)/sys.getsizeof(d)粗略估算（注意getsizeof返回的是对象本身内存，不含键值内容）
替代方案：collections.OrderedDict或weakref.WeakKeyDictionary不缓解rehash压力
这些类型底层仍是哈希表，同样会rehash。OrderedDict还额外维护链表指针，内存开销更大；WeakKeyDictionary只是加了弱引用逻辑，扩容机制完全一致。想绕过rehash，唯一出路是换数据结构：
- 键范围固定且密集？改用
list或array.array索引访问 - 需要范围查询？考虑
sortedcontainers.SortedDict（基于B树，无rehash，但写入慢） - 纯存在性检查？
set比dict轻量，且扩容策略类似，但起始容量更激进
rehash本身不可禁用，但它的发生时机和幅度，完全由你插入数据的方式决定——最常被忽略的，其实是把“边读边写”的逻辑拆成“先读全、再批量写”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
