Go map声明即nil，未初始化赋值会panic；并发读写必加锁；遍历时删键需先收集键再统一删除；键类型必须可比较。
Go 语言的 map 不是“声明即可用”的类型，直接对未初始化的 map 赋值会 panic；并发读写不加锁必崩溃；遍历时删键若不谨慎，逻辑可能被无序性干扰——这些不是边界情况，而是日常高频踩坑点。
map 声明后立即赋值为什么会 panic
因为 var m map[string]int 只声明了一个 nil 指针，底层没分配任何内存。此时 m["k"] = 1 是向空指针写入，Go 运行时直接触发 panic: assignment to entry in nil map。
- 正确做法只有两种：
make(map[string]int)或字面量map[string]int{"k": 1} - 函数参数传入
nil map是安全的（可读），比如v, ok := m["x"]会返回零值和false，但一旦尝试写就崩 - 如果不确定是否已初始化，别靠
if m == nil判断再make——多数时候应由调用方保证初始化，或在函数内统一做防御性初始化
遍历中删除元素的正确姿势
for k := range m { delete(m, k) } 看似自然，但 Go 明确不保证遍历顺序，且底层哈希表可能正在扩容，delete 后继续用 k 做其他 map 操作（比如 m[k]++）会导致行为不可预测。
- 安全模式：先收集键，再统一删 ——
keys := []string{}; for k := range m { if shouldDelete(k) { keys = append(keys, k) } }; for _, k := range keys { delete(m, k) } - 如果只是按值清理（如删掉所有
0值），if m[k] == 0 { delete(m, k) }可以接受，但要清楚这不是“边遍历边删”，而是“查完再删”，本质仍是单轮遍历+条件判断 - 切忌在循环里删完一个键后，还拿这个键去访问、修改其他字段（比如结构体嵌套 map），容易引发竞态或误判
为什么 map 并发读写必须加锁
哪怕一个 goroutine 只读、另一个只写，也大概率触发 fatal error: concurrent map read and map write。这不是概率问题，而是底层 hmap 在扩容时会同时读写多个 bucket，range 和 delete 可能撞在同一块内存上。
立即学习“go语言免费学习笔记（深入）”；
-
sync.RWMutex是最通用解法：读多写少场景下，读操作用RLock/RUnlock，写操作用Lock/Unlock -
sync.Map适合高频读+低频写、且不需要range的场景，但它不支持直接遍历，查Load返回的是 interface{}，需断言；零值查找有额外开销 - 别信“我只读它不会变”——map 底层结构本身就在变（扩容、溢出桶迁移），读操作也可能触发写路径
键类型选错导致编译失败的典型场景
map[[]int]string 或 map[map[string]int]bool 会直接报错 invalid map key type，因为切片、map、函数、含不可比较字段的 struct 都不满足 Go 对“可比较类型”的要求（即能用 == 判等）。
- 合法键示例：
string、int、[4]byte、struct{ ID int; Name string }（所有字段都可比较） - 非法键示例：
[]byte、map[int]string、func()、struct{ Data []byte } - 需要动态组合键？用
fmt.Sprintf("%d-%s", id, name)或strconv.Itoa(id) + "-" + name生成稳定字符串，比硬塞不可比较类型强得多
真正难的不是语法怎么写，而是理解 map 在什么条件下“看起来能跑通，实际一压测就崩”——比如并发场景下加了锁却漏了某处读、遍历时删键用了看似简洁的单行写法、或者把临时拼接的 slice 当作键塞进 map。这些地方不靠经验很难一眼识别。
