Go要求map键必须可比较，而切片、映射和函数不可比较，故编译报错invalid map key type；替代方案包括转为字符串、用全可比较字段的结构体，或采用数组等可比较类型。
Go 的 map 不是“可选工具”，而是处理键值关系的默认且唯一合理选择；用错类型（比如拿 []string 当索引）或忽略零值陷阱，几乎必然导致逻辑错误或 panic。
为什么 map 的 key 不能是切片、map 或函数？
Go 要求所有 map 的 key 类型必须支持相等比较（即能用 == 判断），而 []string、map[string]int、func() 这三类类型在 Go 中不可比较——编译器会直接报错 invalid map key type。
- 常见误写：
map[[]string]int、map[map[string]bool]string，都会编译失败 - 替代方案：若需用“切片内容”作 key，先转成
string（如strings.Join(sl, "|")）或用结构体（字段全为可比较类型） - 结构体作 key 是安全的，但要注意：哪怕只多一个
unexported field或嵌套了[]int，整个结构体就不可比较
map[key]value 访问不存在的 key 时返回什么？
直接下标访问（如 m["missing"]）永远不 panic，但返回对应 value 类型的零值：0、""、false、nil 等。这在统计、缓存等场景极易掩盖 bug。
- 正确判断是否存在：
v, ok := m["key"]，仅当ok == true才表示 key 存在 - 别依赖 “零值 == 不存在”：比如
map[string]int中m["a"]返回0，可能是未设置，也可能是显式设成了0 - 如果业务上需要区分“未设置”和“设为零值”，得换结构，比如用
map[string]*int或封装成自定义类型
并发读写 map 为什么会 panic？
Go 的 map 本身不是并发安全的。一旦有 goroutine 在写（增/删/改），同时另一个在读或写，运行时会立即触发 fatal error: concurrent map read and map write。
立即学习“go语言免费学习笔记（深入）”；
- 最简解法：用
sync.RWMutex包裹读写操作（读多写少时优先RWMutex） - 高频写+低延迟要求场景，考虑
sync.Map，但它只适合读多写少、key 生命周期长的缓存类用途，不推荐用于通用状态管理 - 切忌用
make(map[T]U, 0)初始化后就认为“空 map 可并发读”——空也不行，只要没加锁，任何并发读写都危险
什么时候该用 map，什么时候该用结构体或切片？
map 的核心价值是“通过任意可比较 key 做 O(1) 查找”，不是“存一堆数据”。滥用会导致内存开销大、遍历慢、GC 压力高。
- 用
map：配置项（config["timeout"]）、用户 ID → 用户对象（users[123]）、HTTP header（headers["content-type"]） - 别用
map：固定字段的数据（用struct）、顺序敏感的列表（用[]T）、小范围整数索引（如状态码 200/404，用数组更省空间） - 性能提示：100 个以内键值对，且 key 是连续小整数时，
[]*T比map[int]*T内存占用更低、遍历更快
最容易被忽略的是 key 类型的可比较性约束和并发安全性——它们不会在编译期暴露，却会在运行时突然崩掉，而且崩得毫无征兆。写 map 相关代码前，先默念两遍：这个 key 类型真的能比吗？这段逻辑会不会被多个 goroutine 同时碰？
