go 的 map 非线程安全，并发读写会 panic；sync.Map 适用于高并发读、低频写的场景，但类型受限且 API 不同；需按序遍历、结构体 key、持久化、TTL/LRU 时应选其他方案。
map 是 Go 里最直接的键值存储，但不是线程安全的
Go 的 map 类型天然支持键值对存取，语法简洁，适合单 goroutine 场景。但它在并发读写时会 panic，错误信息是 fatal Error: concurrent map reads and map writes。这不是 bug，而是 Go 故意设计的运行时保护机制。
如果你只是做配置缓存、函数内临时映射、或明确单线程逻辑（比如 CLI 工具初始化阶段），直接用 map[String]interface{} 或带具体类型的 map[string]int 完全没问题。
- 声明方式：
data := make(map[string]int)或字面量data := map[string]bool{"enabled": true} - 零值是
nil，不能对 nil map 赋值，必须先make或用字面量初始化 - 判断键是否存在要靠「双赋值」：
if val, ok := data["key"]; ok { ... }，仅用val := data["key"]拿不到是否存在信息
需要并发安全？别自己加锁，优先用 sync.Map
Go 标准库的 sync.Map 是为高频读、低频写的并发场景优化的，内部做了读写分离和原子操作，比手动用 sync.RWMutex 包一层普通 map 更轻量（尤其读多时）。
但它有明显限制：键和值类型只能是 Interface{}，不支持泛型，且 API 不同于原生 map —— 没有 len()、不支持 range 直接遍历（得用 Range() 方法）、没有「获取并判断存在」的一行写法。
立即学习“go语言免费学习笔记（深入）”；
- 写入：
m.Store("key", 42) - 读取：
if val, ok := m.Load("key"); ok { ... } - 删除：
m.delete("key") - 遍历：
m.Range(func(key, value interface{}) bool { ... return true })（return false 可提前退出）
什么时候该换别的方案？
如果需求超出 map 或 sync.Map 能力边界，就该换：
- 需要按插入顺序遍历 → 用 slice + map 组合，或者第三方库如
github.com/elliotchance/orderedmap - 键不是 string 或基本类型（比如结构体作 key）→ 确保 key 类型可比较（字段都可比较），否则编译报错
invalid map key type - 数据量大、需持久化或复杂查询 → 别硬扛，上 sqlite（
mattn/go-sqlite3）或 BadgerDB 这类嵌入式 KV - 要 TTL（过期时间）或 LRU 驱逐 →
github.com/hashicorp/golang-lru或github.com/bluele/gcache更合适
package main import "fmt" func main() { // 基础 map 示例 cfg := make(map[string]string) cfg["host"] = "localhost" cfg["port"] = "8080" if v, ok := cfg["timeout"]; !ok { fmt.Println("timeout not set") } // sync.Map 示例 var cache sync.Map cache.Store("user_123", "Alice") if val, ok := cache.Load("user_123"); ok { fmt.Printf("found: %sn", val) } } 真正容易被忽略的是：**sync.Map 的 zero-value 是可用的，不需要显式初始化**——这和普通 map 不同。另外，它不适合频繁写入场景（比如每毫秒更新），此时 sync.RWMutex + 普通 map 反而更可控。