Python集合的迭代顺序由其底层哈希表的结构决定，但该顺序既非按元素值排序，也非严格按哈希值模运算结果排列；它取决于动态调整的哈希表容量、插入顺序及CPython的具体实现策略，且不保证跨版本或跨运行的一致性。
python集合的迭代顺序由其底层哈希表的结构决定，但该顺序既非按元素值排序，也非严格按哈希值模运算结果排列；它取决于动态调整的哈希表容量、插入顺序及cpython的具体实现策略，且不保证跨版本或跨运行的一致性。
在Python中，set 是基于开放寻址法（open addressing）实现的哈希表，其核心目标是高效支持 O(1) 平均时间复杂度的成员检测与去重操作，而非提供可预测的遍历顺序。你观察到的现象——对 'abcdef' 调用 set() 后得到 {'c','d','f','b','a','e'} 的输出顺序——并非偶然，而是 CPython 当前（截至2026年）哈希表扩容策略与散列分布共同作用的结果。
关键点在于：哈希表初始容量并非固定为8，且扩容规则并非简单的“填充超60%即×2”。根据CPython源码与官方文档确认：
- 小型集合（如元素数 ≤ 5）的初始哈希表大小为 8；
- 但当首次触发扩容时，容量会乘以4（而非2），即从8 → 32（而非8 → 16）；
- 这一设计旨在减少小规模数据下的哈希冲突，提升早期性能；
- 后续扩容才逐步转向更保守的倍增策略（如 ×2），并受动态负载因子（load factor）调控（当前默认约为 0.625，即 5/8，已从历史上的 2/3 调整而来）。
因此，你使用 hash(i) % 32 成功预测顺序，正是因为实际哈希表此时已扩容至 32 个槽位（buckets），而 hash(i) % 16 失败，是因为假设的16槽表并未被采用。
下面通过代码验证这一行为：
# 观察不同大小集合的实际哈希表容量（需借助内部调试接口，生产环境勿用）
import sys
def get_set_size(s):
# 注意：_sizeof() 是CPython私有API，仅用于教学分析，不可依赖
try:
return sys.getsizeof(s)
except:
return "N/A"
s6 = set('abcdef')
print(f"6-element set size (approx): {get_set_size(s6)} bytes") # 典型值：~232–280，暗示底层结构含32+ slots
更重要的是，即使哈希表大小确定，迭代顺序也不等于“按 hash(x) % N 升序排列”。CPython在遍历时按内存中桶（bucket）的物理顺序扫描，而插入过程可能因探测序列（probe sequence）导致元素在表中非连续存放。例如，若 'a' 的哈希模32结果为1，但位置1已被占用，则它会被存放到下一个可用位置（如2、3…），从而打破数值顺序。
✅ 正确理解与实践建议：
- ✅ 永远不要依赖集合的迭代顺序：它是实现细节，CPython未承诺稳定性，未来版本可能变更（如引入随机化哈希种子、新探测算法等）；
- ✅ 需要有序集合？请显式转换：sorted(my_set)（返回列表）、list(my_set)（无序但可预测）或使用第三方库如 ordered-set；
- ✅ 去重 + 保序？推荐 dict.fromkeys(iterable).keys()（Python 3.7+ dict保持插入顺序）：
ordered_unique = list(dict.fromkeys(['a','b','a','c','b'])) # ['a','b','c']
- ⚠️ 空集合 set() 与空字典 {} 字面量语法易混淆，务必用 set() 构造空集，避免逻辑错误。
总结而言，你敏锐地捕捉到了哈希表扩容的线索，但将“顺序”等同于“哈希模值排序”是一种常见误解。集合的本质是无序唯一容器——它的强大源于数学集合语义与哈希性能，而非序列行为。尊重其设计契约，方能写出健壮、可移植的Python代码。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
