Go map底层是哈希表，非红黑树，不保证遍历顺序；必须make初始化，否则写入panic；非并发安全，多goroutine写需加锁；key必须可比较，slice/func/map等不可用作key。
Go map 是哈希表，不是红黑树
Go 的 map 底层是哈希表（hash table），不是平衡二叉树。这意味着它不保证遍历顺序，也不支持按 key 排序访问——如果你需要有序遍历，得额外用 sort 或维护一个切片存 key。
常见错误现象：for range map 每次运行结果顺序不同，有人误以为是 bug，其实是设计如此。
- 哈希表实现带来 O(1) 平均查找/插入性能，但 worst-case 退化为 O(n)，比如大量哈希冲突时
- Go 1.12+ 对哈希函数做了随机化（启动时加随机种子），进一步防止攻击者构造恶意 key 导致哈希碰撞攻击
- 底层结构包含
hmap、bmap（bucket）、overflow链表等，但这些类型不对外暴露，不能直接操作
map 必须 make 初始化，否则 panic
声明但未初始化的 map 是 nil，对它做 delete 或写入会 panic，读取（如 v, ok := m[k]）则安全。
错误示例：var m map[string]int; m["a"] = 1 → panic: assignment to entry in nil map
立即学习“go语言免费学习笔记（深入）”；
- 正确做法只有两种：
m := make(map[string]int)或m := map[string]int{"a": 1} - 嵌套 map 更容易踩坑，比如
m := make(map[string]map[int]string)只初始化了外层，m["x"][1] = "y"仍 panic —— 内层要单独make - struct 中嵌入 map 字段，同样需要在 struct 初始化后手动
make，不会自动初始化
map 不是并发安全的，多 goroutine 写必须加锁
Go 的原生 map 没有内置锁，多个 goroutine 同时写（或一写多读）会触发 fatal error：fatal error: concurrent map writes。
注意：只读是安全的；但只要有一个 goroutine 在写，其他所有 goroutine（无论读写）都可能出问题。
- 简单场景用
sync.RWMutex包一层最直接，读多写少时性能可接受 - 高频写 + 低冲突场景考虑
sync.Map，但它只适合“读远多于写”且 key 类型固定（避免 interface{} 开销） -
sync.Map的LoadOrStore、Range行为和原生 map 不同（比如Range不保证看到最新写入），别想当然替换 - 千万别用
defer mu.Unlock()在循环里锁 map —— 容易锁太久，阻塞其他 goroutine
map 的 key 类型有限制，不是所有类型都能用
Go 要求 map 的 key 必须是「可比较的」（comparable），即支持 == 和 != 运算符。编译器会在 build 时检查，不满足就报错。
典型错误：map[[]int]string、map[func()]int、map[map[string]int]bool 都非法，因为 slice、func、map 本身不可比较。
- 合法 key 类型包括：基本类型（
int、string、bool）、指针、channel、interface{}（但 runtime 要求实际值可比较）、struct（所有字段都可比较）、array（元素类型可比较） -
string作 key 很常见，但要注意：空字符串""和nil字符串（var s string）是同一个值，没问题；但不要误用*string当 key，容易出现 nil 指针比较 - 自定义 struct 作 key 时，如果含 slice 字段，哪怕不参与比较逻辑，也会让整个 struct 不可比较 —— 编译直接拒
