Python 的 set 不保留插入顺序，其迭代顺序由哈希表槽位决定，属实现细节且不可靠；需有序唯一数据时应选用 dict（3.7+）、OrderedDict 或 sorted() 等替代方案。
Python 中的 set 不保留插入顺序，无论你按什么顺序添加元素，迭代时的输出顺序都不可预测、不保证、也不应被依赖。
为什么看起来有时“像有顺序”
在某些小规模数据下（比如 set('abcdef')），你可能多次看到相同输出顺序，例如 {'c', 'd', 'f', 'b', 'a', 'e'}。这并非因为 set 记住了插入顺序，而是当前 CPython 实现中哈希表容量为 32、元素散列后恰好落入固定槽位，导致遍历时按内存槽位顺序呈现。一旦添加第 7 个元素触发扩容，或换一个 Python 版本、甚至重启解释器，顺序就可能改变。
插入顺序完全不影响迭代结果
以下操作不会让 set 按你添加的先后顺序返回元素：
- 用
set([1,2,3])或{3,1,2}创建集合，内部立即打乱存储位置 - 连续调用
.add()多次，每次插入都重新计算哈希并定位槽位，不维护链式关系 - 即使所有元素 hash 值递增，也不意味着迭代时按 hash 排序——底层是开放寻址哈希表，遍历的是桶数组索引顺序
需要有序唯一数据？选对容器
若业务逻辑要求元素按插入顺序或大小顺序排列，请明确选用替代方案：
-
保持插入顺序：用
collections.OrderedDict.fromkeys(...)（Python dict（3.7+ 保证插入序），再取list(dict.keys())；或第三方库如ordered-set -
按值自然排序：用
sorted(set_data)转为列表，或每次需要时重建tree_set = sorted(my_set) -
Java 场景：选
LinkedHashSet（插入序）或TreeSet（排序序），而非HashSet
验证顺序是否稳定？别试
不要写测试代码反复打印 list(my_set) 来“确认”它这次有没有变。这种行为本身就在误用 set 的语义。语言规范只承诺两点：元素唯一、成员检测快。其余一切——包括看似稳定的输出——都是实现细节，随时可能变更。
