for-each遍历不可变Set时顺序不保证，是规范行为而非bug；应只校验元素存在性、大小和去重性，避免依赖或断言顺序。
java 中的 for-each 循环可以遍历任何实现了 iterable 接口的集合，包括不可变的 set（如 set.of() 或 immutableset）。但关键在于：set 本身不保证插入或遍历顺序，而具体实现类决定实际输出是否“有序”。所谓“哈希扰动”，本质是哈希表内部桶分布与迭代器遍历逻辑共同作用的结果，并非随机，但对用户而言常显得“不可预测”。
不可变 Set 的常见实现及其遍历行为
Java 9+ 的 Set.of() 返回的是私有静态内部类（如 ImmutableSetN 或 ImmutableSet12），其底层并非基于 HashMap，而是紧凑数组 + 哈希探测，不保留插入顺序，也不按哈希值排序。迭代顺序取决于元素哈希值、容量与内部散列算法，且随 JVM 版本/元素数量可能变化。
-
Set.of("a", "b", "c")每次运行输出可能为a, b, c或b, a, c—— 不是 bug，是规范允许的行为 -
Set.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)在小规模时可能看似有序，实为巧合；加入100后顺序很可能突变 - 若需稳定顺序，请显式选用
LinkedHashSet（插入序）或TreeSet（自然序/定制序），哪怕包装成不可变视图（如Collections.unmodifiableSet(new LinkedHashSet(...))）
for-each 遍历不可变 Set 的正确预期
for-each 仅调用集合的 iterator() 方法，它返回的迭代器行为完全由该 Set 实现定义。对不可变哈希型 Set，应默认接受：遍历顺序无业务含义、不可依赖、不应测试断言具体顺序。
- 错误做法：写单元测试断言
set.iterator().next() == "first"或用assertEquals(List.of("x","y"), new ArrayList(set)) - 正确做法：测试关注“是否包含全部元素”“大小是否正确”“无重复”，例如
assertTrue(set.containsAll(expected)) && set.size() == expected.size() - 若日志或调试需要可读性，可先转为
TreeSet再遍历：for (String s : new TreeSet(myImmutableSet)) { ... }
哈希扰动的真实来源：不是“打乱”，而是“无约定”
所谓“哈希扰动”，常被误解为系统故意打乱顺序。实际上，JDK 的不可变 Set 实现只为节省内存和提升构建/查询性能做了高度优化，根本未承诺任何顺序语义。其内部哈希计算（如 Objects.hashCode()）、模运算取桶、线性探测冲突处理等步骤，在不同元素组合下自然导致迭代路径差异。
- 同一段代码在 JDK 17 和 JDK 21 中，相同元素的
Set.of()迭代顺序可能不同（因内部实现微调） - 字符串
"abc"和"bca"哈希值不同，放入小容量不可变 Set 后位置相邻与否，直接影响for-each先后 - 没有“扰动算法”，只有“未定义顺序”——这是 Set 接口契约的一部分，而非缺陷
不复杂但容易忽略：只要不用顺序做逻辑分支或断言，for-each 遍历不可变 Set 就是安全高效的。真正要防的，是隐式依赖顺序的思维惯性。
