sync.Map.Range 必须传入 func(key, value interface{}) bool 类型回调函数，返回 true 继续遍历、false 终止；不支持 for range，因内部 read/write 分离结构未暴露迭代器接口，且 Go 不允许自定义类型实现 range 协议。
sync.Map.Range 的回调函数必须接收两个参数
sync.Map.Range 不像普通 map 那样支持 for range，它要求你传入一个函数，该函数签名必须是 func(key, value interface{}) bool。如果只写一个参数或类型不匹配，编译直接报错：cannot use … as func(interface{}, interface{}) bool value。
这个函数返回 bool：返回 true 继续遍历，false 立即终止（类似 break）。注意它不是“跳过当前项”，而是彻底退出遍历 —— 没有类似 continue 的机制。
- key 和 value 类型都是
interface{}，需手动断言，比如key.(string)或value.(*MyStruct) - 不要在回调里对
sync.Map做写操作（如Store、Delete），虽然不会 panic，但行为未定义，可能漏掉新写入的键或重复遍历旧键 - Range 是快照式遍历：它不阻塞写操作，但看到的 key-value 对可能已过期（被后续
Delete掉），也可能看不到刚Store的新条目
为什么不能用 for range 遍历 sync.Map
因为 sync.Map 内部结构不是普通哈希表，它用了 read/write 分离 + dirty map 两层设计，没有暴露迭代器接口。Go 语言本身也不允许为自定义类型实现 range 协议（那需要编译器支持），所以 for k, v := range myMap 语法根本无法通过编译。
常见错误是误以为 sync.Map 和普通 map 一样可用 range，结果得到编译错误：cannot range over myMap (type *sync.Map)。
- 别试图用反射或 unsafe 强行取内部字段遍历 —— 字段名带下划线（如
_read）、结构不稳定、跨版本不兼容 - 如果真需要稳定顺序或全量快照，建议先用
Range把所有键值拷到切片里，再排序或处理
Range 遍历时并发读写的实际表现
sync.Map.Range 本身是并发安全的，但它和其它操作（Load、Store）之间**不构成事务性一致性**。举个典型场景：你调用 Range 遍历 1000 个键，中间另一个 goroutine 删除了其中 5 个 —— Range 可能仍会把这 5 个键值返回给你，也可能跳过它们，取决于 dirty map 刷入时机和读路径是否命中。
- Range 不加锁，性能比全量加锁遍历高，但结果是“尽力而为”的最终一致视图
- 如果业务逻辑依赖“遍历时看到的一定是当前存活键”，那就不能依赖 Range，得改用互斥锁保护普通 map
- 高频写 + 低频读场景下，Range 效率尚可；但若写操作密集（比如每秒数千次 Store/Delete），Range 返回结果延迟可能明显
替代方案：什么时候该放弃 sync.Map.Range
当你需要精确控制遍历顺序（如按 key 字典序）、需要原子性保证（遍历期间无任何写干扰）、或频繁执行全量遍历（>100ms/次），sync.Map 就不是最优解。
- 用
sync.RWMutex+ 普通map[string]interface{}：读多写少时，读锁开销极小，且 range 完全可控 - 用第三方库如
golang.org/x/exp/maps（Go 1.21+）配合maps.Keys+sort，再 range —— 但注意它本身不并发安全，仍需外层锁 - 避免在 Range 回调里做耗时操作（如 HTTP 请求、数据库查询），否则会拖慢整个 Map 的读性能，因为 Range 内部会串行调用你的函数
sync.Map 的设计初衷是“稀疏写、密集读”的缓存场景，Range 只是配套工具，不是通用迭代器。真要高频全量扫描，它反而成了瓶颈。
