sync.Map 没有内置 Range 方法，但提供了 Range(func(key, value interface{}) bool) 高阶函数实现伪遍历；它不保证原子快照、顺序或完整性，仅确保每个存活键值对至少被回调一次，适用于读多写少且无需强一致性的场景。
sync.Map 没有内置 Range 方法，别硬套 map 的遍历习惯
Go 的 sync.Map 本质不是线程安全的哈希表封装，而是为「读多写少」场景优化的特殊结构，它**故意不提供迭代能力**。你写 syncMap.Range(...) 会直接编译报错 —— 因为它压根没定义这个方法。这不是遗漏，是设计取舍：避免在遍历时锁整个 map 或产生不一致快照。
用 Range 函数参数实现“伪遍历”，但要注意数据可能跳变
sync.Map 提供了 Range 方法，但它是个高阶函数，签名是 Range(func(key, value interface{}) bool)。你传进去的回调会被逐个调用，但：
- 回调中返回
false可提前终止，返回true继续 - 遍历过程不加全局锁，不同 goroutine 写操作可能在遍历中途生效，导致某 key 被漏掉、或同一 key 被重复看到（取决于底层分片状态）
- 无法保证顺序，也不承诺原子性快照 —— 它只保证「每个已存在且未被删除的 key-value 对，至少被调用一次」
示例：
var m sync.Map
m.Store("a", 1)
m.Store("b", 2)
m.Range(func(key, value interface{}) bool {
fmt.Println(key, value) // 可能输出 a 1、b 2；也可能只输出其中一个
return true // 继续
})
需要稳定快照？自己转成普通 map 再遍历
如果业务逻辑要求「遍历时看到的 key 集合必须完整且不变」（比如做配置同步、批量推送），sync.Map.Range 不够用。这时得手动构造快照：
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
Range把所有当前存活项收集到一个临时map[interface{}]interface{}中 - 再对这个普通 map 做常规
for range—— 此时它是内存中的静态副本 - 注意：收集过程本身仍非原子，但后续遍历完全安全
简写示例：
snapshot := make(map[interface{}]interface{})
m.Range(func(k, v interface{}) bool {
snapshot[k] = v
return true
})
for k, v := range snapshot {
fmt.Println(k, v) // 这里可放心排序、修改、嵌套遍历
}
为什么不用 RWMutex + 普通 map 替代 sync.Map？
很多人一上来就想换回 map 加 sync.RWMutex，觉得更可控。但要注意：
- 高频读场景下，
RWMutex.RLock()仍有调度开销，而sync.Map的 read-only 分支几乎无锁 - 写操作少于 10% 时，
sync.Map性能通常更好；反之，带锁 map 更简单直观 -
sync.Map不支持len()、不暴露 keys 切片、不能用delete()以外的方式清空 —— 这些限制本身就是提示：它不适合需要强一致性遍历的场景
真要频繁迭代，优先考虑重构数据结构，比如拆出一份只读副本，或改用 concurrent-map 这类第三方库（它们明确提供快照式迭代）。
最常被忽略的一点：sync.Map 的「并发安全」不等于「遍历安全」，它的 Range 是妥协产物，不是替代品。
