Go中map声明后为nil，直接赋值会panic；必须用make或字面量初始化；读取需用v,ok:=m[k]判断存在性；遍历时删除要先收集键再统一删；并发读写必须加锁。
Go 里 map 不是“声明即可用”，而是“声明即 nil，写就 panic”——这是最常踩的坑，没有之一。
为什么 var m map[string]int 后直接赋值会崩溃
因为 var m map[string]int 只是声明了一个 nil 指针，不是空 map。底层值为 nil，此时执行 m["k"] = 1 会立即触发 panic: assignment to entry in nil map。
- 安全初始化只有两种方式：
m := make(map[string]int)或m := map[string]int{"k": 1} - 结构体中嵌套
map字段也一样：只声明不make，调用方法时一写就崩 - 测试容易漏掉——
v := m["x"]返回零值不会 panic，但掩盖了未初始化问题
读 key 存在性必须用双返回值 v, ok := m["k"]
单返回值写法 v := m["k"] 永远不报错，但无法区分“key 不存在”和“key 存在但值恰好是零值（如 0、""、false）”。这在配置解析、API 响应解包等场景极易埋雷。
- 正确写法：
if v, ok := m["timeout"]; ok { /* 真实存在 */ } - 漏掉
ok检查，可能让 bug 潜伏数月，直到某次数据恰好为零值才暴露 - 尤其注意：
map[string]*int类型中，v == nil不能代替ok == false，因为 key 存在但值为nil是合法的
遍历时删元素必须分两步：先收键，再统一删
Go 允许在 for range 中调用 delete()，但边遍历边删键会导致行为不可靠——不是 bug，是设计使然：哈希表可能正在扩容，且遍历顺序本就不保证。
立即学习“go语言免费学习笔记（深入）”；
- 危险写法：
for k := range m { if shouldDelete(k) { delete(m, k) } }—— 下一轮range可能已重排，k对应的值已变 - 安全写法：先收集键
keysToDelete := []string{}，再统一删for _, k := range keysToDelete { delete(m, k) } - 例外：仅依赖值判断删除（如
if m[k] == 0 { delete(m, k) }）可直接写，但需确认逻辑不受遍历无序性干扰
并发读写 map 必须加锁，别信“只读不写就安全”
原生 map 完全不是线程安全的。哪怕一个 goroutine 在 range，另一个在 delete 或赋值，大概率触发 fatal error: concurrent map read and map write。
-
sync.RWMutex是通用解法：读前RLock()，写前Lock() -
sync.Map适合读远多于写的场景（如配置缓存），但它不支持len()、不支持range，且零值查找有额外开销 - 最隐蔽的坑是“看起来能跑通”：本地压测没出事 ≠ 线上安全；底层哈希表扩容时会同时读写多个 bucket，race detector 一抓一个准
真正麻烦的从来不是语法怎么写，而是那些“运行时不报错但语义错误”的写法：没检查 ok、没加锁、依赖遍历顺序、把未初始化的 map 当空 map 用——它们会在某个流量高峰、某次部署、某条特殊数据进来时突然爆发。
