先记住这个答案
Go 规范只保证 map 的迭代顺序不固定，实际运行时会刻意随机化起点，因此两次 range 的顺序几乎肯定不同。要稳定输出，应先取出所有 key 存入切片，用 sort.Sort 或 sort.Slice 定义排序规则，再按排序后的 key 从 map 中取值。若 key 是自定义类型，需提供比较函数；若需按 value 排序，则需排序键值对结构。
- 遍历顺序规范不保证，非纯随机但会变
- 稳定输出先收集 key 排序再取值
- 排序代价 O(n log n)，小 map 无感
为什么每次遍历顺序都不同
Go 语言规范明确写着：map 的迭代顺序未定义，即使同一个 map 两次遍历，顺序也可能不同。这不是 bug，而是刻意设计——让程序员不能依赖任何稳定的顺序，避免写出跨实现或跨版本不兼容的代码。运行时的实现会在遍历开始时从某个随机 bucket 出发，然后按顺序遍历所有 bucket，因此你几乎无法预测下一次 range 会先遇到哪个 key。
本质上，map 是哈希表，bucket 里还叠加溢出链，遍历要跨 bucket、穿链表。若强行固定顺序，每次插入删除都会让内部布局变化，那保持稳定顺序的成本极高。语言选择不承诺，让调用方在需要时自己排序。这也解释了你看到的现象：同一次程序里多次遍历，每次输出都不同，但偶尔碰巧相同也不是异常。
稳定输出服务器配置项列表
假设你有一个 map 保存多个服务节点的状态："node-1" 到 "node-5"，对应 IP。在管理面板展示时，需要每次刷新都让节点按固定顺序出现，否则用户会觉得列表乱跳。简单 range 直接打印的话，刷新一次顺序就变一次，显然不可用。决策是：先取出所有 key 放入 []string，然后 sort.Strings(keys)，最后循环 keys 并 m[key] 取值。这样输出总是 node-1, node-2, ... 按字典序。
这个过程的时间复杂度是 O(n log n)，主要消耗在排序。如果 map 很小，比如不到 100 个 key，排序耗时远小于网络或打印开销，完全可忽略。但若 map 极大并且频繁调用，需要评估是否真是必要。可以考虑缓存排序后的 key 列表，只在 map 变更时重新生成，但前提是你对 map 的写入是可控且低频的——比如启动后只读，那么只需要排序一次。
什么条件下这个方案会失效
当 key 是自定义结构体，没有自然顺序，sort.Slice 需要你提供 less 函数。如果结构体里有多个字段，你必须定义清楚按哪个字段排，否则难以保证结果稳定。更麻烦的是，若 map 的 value 本身包含敏感或大值，而你想按 value 排序，只排 key 就不行了——需要先把键值对组成切片，再按 value 排序，最后输出。这会增加内存占用和代码复杂度。
还有并发场景：如果 map 在排序过程中被其它 goroutine 并发写，那次 range 本身就是不安全的（会 panic）。先复制 key 再做排序和取值也有窗口，若期间 map 被修改，你取到的值可能不是排序那一刻的状态。要真正稳定且安全，要么加读写锁把遍历和排序整个锁住，要么用 immutable 快照，但这当然削弱了并发的吞吐。
容易答错的地方
- 遍历顺序是“伪随机”
- 以为它像 math/rand 一样均匀分布，但实现只是随机起点，并没有保证概率均匀。规范不承诺任何随机性质，你只能靠 sort 固定输出。
- 用 range map 的第一个元素当最小 key
- 由于顺序不定，第一次拿到的可能是任意 key，拿它当最小值或用于算法参考会出错。必须先排序或线性扫描找最值。
面试官还会怎么问？
如果 key 是结构体且想按内部 value 排序，怎么做？
先把所有键值对组成 []struct{key T; value V}，再用 sort.Slice 根据 value 排序。注意排序稳定性：若 value 相等，可再按 key 二级排序，让输出完全确定。
同一个 map 连续遍历两次，顺序会不会完全一样？
有可能，但不要依赖。运行时的随机起点可能导致不同，但概率上也可能相同。规范不保证，所以必须当顺序可能不同来设计。
为什么 Go 不直接按 key 排序后返回？
因为 map 设计目标是常数级读写，每次遍历都排序会使 O(n log n)，破坏性能；而且语言层面保证排序会让实现复杂且锁死低层结构。将排序权交给用户更灵活。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。