对nil map写入会直接panic，必须用make初始化；对nil slice的append、len、range等操作安全，但下标访问会越界panic。
对 nil map 写入会直接 panic
Go 里往 nil map 里写键值（比如 m["k"] = v 或 delete(m, "k")）是运行时错误，程序立即崩溃，报错 panic: assignment to entry in nil map。这不是空指针解引用那种未定义行为，而是 Go 运行时主动拦截并终止的确定性 panic。
常见错误场景：函数返回一个未初始化的 map[string]int 变量，调用方直接往里塞数据；或者结构体字段是 map 类型但没在构造时做 make。
- 必须显式用
make(map[K]V)初始化才能写 - 读操作（
v, ok := m[k]）对nilmap 是安全的，返回零值和false - 判断是否为 nil 可用
m == nil，但通常不如直接初始化来得可靠
对 nil slice 读写大部分是安全的
nil slice 的底层指针为 nil，但长度和容量都是 0，这使得它在很多操作中表现得像空 slice：len(s) == 0、cap(s) == 0、for range s 不执行循环体、s[i]（越界）仍会 panic —— 但这个 panic 和 nil 无关，是数组越界。
真正要注意的是 append：对 nil slice 调用 append 是完全合法的，Go 会自动分配底层数组并返回新 slice。所以 s = append(s, x) 在 s 为 nil 时不会出错。
立即学习“go语言免费学习笔记（深入）”；
-
append安全，且是推荐的“懒初始化”方式 -
s[0]或s[i]（任意下标）会 panic：panic: runtime error: index out of range [0] with length 0 -
copy(dst, src)对nilsrc 是安全的（复制 0 个元素），dst 为nil则要求 len(dst) == 0
map 和 slice 的零值语义差异是根源
Go 把 map 和 slice 都设计成引用类型，但它们的零值行为完全不同：map 的零值是 nil，且禁止写；slice 的零值也是 nil，但多数操作不依赖底层指针非空，只依赖长度信息。
这种不对称不是 bug，而是有意为之的设计取舍：map 内部需要哈希表结构，未初始化就写毫无意义；slice 则可看作“带长度的指针”，长度为 0 时很多只读或追加逻辑天然成立。
- 别试图统一处理 “nil 安全”——map 要早初始化，slice 可晚初始化
- 函数参数接收
map时，如果可能被写入，文档或注释应明确要求 caller 保证非 nil - 结构体中嵌入 map 字段，应在 NewXXX 构造函数里用
make初始化，而不是留空
调试时如何快速定位 nil map panic
panic 信息本身不显示变量名，只说 assignment to entry in nil map，堆栈顶通常是你的赋值行。但如果逻辑复杂（比如在闭包、方法链、map 嵌套中赋值），光看行号容易误判。
建议在疑似位置加一句 if m == nil { panic("m is nil at xxx") }，提前暴露问题；或者用 delve 断点停在 panic 前，检查 map 变量的实际值。
- vscode-go 或 goland 的 debug 模式下，hover 看变量值时，
nilmap 显示为map[]，而非空 map 显示为map[k:v] - log 打印前先
fmt.Printf("m=%v, m==nil? %t\n", m, m == nil)，比猜更省时间 - 静态检查工具如
staticcheck能捕获部分明显未初始化 map 的写操作，但无法覆盖所有路径
nil map 的 panic 是硬性边界，绕不开也压不住；nil slice 的宽容则是有前提的——只要你不越界、不传给要求非 nil 的接口，它就能一直安静待着。这点差异，得刻进肌肉记忆里。
