Go 中 map 遍历顺序随机是故意设计的安全特性，防止攻击者推测内存布局；遍历时删除元素应先收集 key 再统一删除，并发访问需加锁，获取有序键需手动提取并排序。
Go 中 map 遍历为什么每次顺序都不一样
因为 Go 语言从 1.0 起就**故意让 map 遍历随机化**，防止开发者依赖固定顺序。这不是 bug，是安全设计——避免攻击者通过探测遍历顺序推测内存布局或哈希实现。
实际表现：同一段代码，多次运行 for k, v := range myMap，k 的输出顺序几乎必然不同；即使 map 内容没变、程序没重启，只要进程重跑，顺序就可能变。
- 不依赖顺序：所有基于「先遍历到的 key 一定是某个特定值」的逻辑都不可靠
- 测试时别断言遍历顺序：比如用
reflect.DeepEqual比较两个 map 的 keys 切片，容易因顺序不一致而误报失败 - 真要固定顺序？得手动排序：把 keys 提出来，用
sort.Strings或sort.Slice排好再遍历
如何安全地在遍历中删除 map 元素
直接在 range 循环里调用 delete(myMap, k) 是允许的，也不会 panic，但结果不可预测：被删的 key 可能已被当前迭代读过，也可能还没轮到——你无法控制它是否还会出现在后续 iteration 中。
更糟的是，如果删除后又插入新 key（尤其哈希冲突较多时），该新 key 有可能在本轮循环中被再次遍历到（Go 运行时不保证“已遍历过的桶不再访问”）。
立即学习“go语言免费学习笔记（深入）”；
- 推荐做法：先收集要删的 key，遍历完再统一删 ——
keysToDelete := make([]string, 0, len(myMap))，循环中append(keysToDelete, k)，结束后for _, k := range keysToDelete { delete(myMap, k) } - 并发场景必须加锁：哪怕只读也要注意，map 本身不是 goroutine-safe；用
sync.RWMutex或改用sync.Map（但注意sync.Map不支持直接遍历 + 删除组合操作） - 别用
len(myMap) == 0判断是否删干净：删除过程中长度实时变化，但 range 迭代器在开始时已确定遍历范围，所以删不影响当前循环次数
获取 map 的所有键或值，且保持可预测顺序
Go 标准库不提供内置的有序 keys 方法，必须手动提取+排序。常见错误是试图用 map.Keys()（这根本不存在）或假设 reflect.Value.MapKeys() 返回有序结果（它不保证）。
正确姿势取决于 key 类型：
- 字符串 key：
keys := make([]string, 0, len(myMap)); for k := range myMap { keys = append(keys, k) }; sort.Strings(keys) - 整数 key：
sort.Ints(keys)或sort.Slice(keys, func(i, j int) bool { return keys[i] - 自定义 struct key：必须实现
sort.Interface，或用sort.Slice配合比较函数 - 值集合同理：先
vals := make([]T, 0, len(myMap))，再for _, v := range myMap { vals = append(vals, v) }，但注意：值顺序和 key 顺序无对应关系，除非你按排好序的 keys 重新取值
为什么用 sync.Map 不能直接 range，以及替代方案
sync.Map 是为高并发读多写少场景优化的，但它**不支持原生 range 语法**。尝试 for k, v := range mySyncMap 会编译失败 —— 因为它没有实现 map 类型的迭代协议。
它的遍历只能靠 Range(f func(key, value interface{}) bool) 方法，且该方法是快照式遍历：执行期间其他 goroutine 的增删不会影响本次遍历结果，但你也无法中途 break（除非 f 返回 false）。
- 需要中断？只能靠闭包变量控制，例如
found := false; mySyncMap.Range(func(k, v interface{}) bool { if k == target { found = true; return false }; return true }) - 想边遍历边删？不行。
Range中调用Delete是安全的，但不会反映在本次遍历中，且不能保证原子性；应先收集 key，再批量删 - 真要频繁遍历+修改，不如回到普通 map +
sync.RWMutex，尤其当 map size 小、并发度不高时，性能差异远小于逻辑复杂度代价
