Go nil map 读取和写入行为为什么相反

Go 里最容易让人误判的 map 场景之一，是同一个 nil map 对读取很宽容，对写入却直接 panic。原因并不是读取“创建了一个空 map”，而是语言规范把 nil map 定义为一个不能增加元素的空 map：索引读取可以返回元素类型的零值，给元素赋值则不允许。

因此，var counts map[string]int 可以安全地读取和遍历，但不能执行 counts["ok"] = 1。修复写入问题的关键也很明确：在第一次写入前，用 make 或 map 字面量初始化，而不是只判断某个键是否存在。

一、先确认 nil map 到底代表什么

声明 map 变量但不初始化时，变量值是 nil。它与 make(map[string]int) 得到的空 map 都没有元素，所以读取同一个缺失键时，看起来结果相同；差别在于前者没有可供新增元素使用的 map 状态。

package main

import "fmt"

func main() {
	// 声明只产生 nil map，不会分配可写的 map 存储。
	var nilMap map[string]int
	emptyMap := make(map[string]int)

	// 两者读取缺失键都会返回 int 的零值 0。
	fmt.Println(nilMap["missing"], emptyMap["missing"])
	fmt.Println(nilMap == nil, emptyMap == nil)
}

规范中的关键句是：nil map 等价于空 map，但不能向其中添加元素。也就是说，读取路径只需要一个“查不到时返回什么”的结果；写入路径还需要一个已经初始化的底层 map。两条路径的资源要求不同，行为自然不会对称。

二、把读取、判断和写入拆开排查

看到读取结果是 0 时，不要马上认为键真的存了整数 0。map 的二值索引能把“键不存在”和“键存在但值恰好为零”区分开：

// readCount 只负责读取，不会修改传入的 map。
func readCount(m map[string]int, key string) (int, bool) {
	value, ok := m[key]
	// ok 表示键是否存在，不受 value 是否为零影响。
	return value, ok
}

// 调用方可以传 nil map；读取仍然得到零值和 false。
value, ok := readCount(nil, "jobs")
fmt.Println(value, ok) // 0 false

排查时可以按三个观察点缩小范围：m == nil 判断是否从未初始化，len(m) 判断当前元素数量，value, ok := m[key] 判断键是否存在。它们不会把 nil map 变成空 map，也不会为后续写入自动准备空间。

常见错误发生在最后一步：

func addCount(m map[string]int, key string) {
	// 这里假设 m 已经初始化；若调用方传入 nil，会在赋值处 panic。
	m[key]++
}

// addCount(nil, "jobs") 会触发：assignment to entry in nil map

三、用正确的初始化方式修复写入

修复方案取决于谁拥有 map 的初始化责任。最简单的是在创建对象时初始化：

type Counter struct {
	Counts map[string]int
}

func newCounter() *Counter {
	// 构造函数建立可写状态，后续方法只处理业务数据。
	return &Counter{Counts: make(map[string]int)}
}

如果函数接收的是可选 map，且函数本身必须负责写入，可以在入口建立局部副本。但要注意：map 是引用语义，给参数重新赋值不会让调用方变量自动指向新 map，所以需要返回它：

func put(m map[string]int, key string, value int) map[string]int {
	if m == nil {
		// 只在第一次写入前初始化，避免对已经可用的 map 重复替换。
		m = make(map[string]int)
	}
	m[key] = value
	return m
}

counts := put(nil, "jobs", 1)
fmt.Println(counts["jobs"]) // 1

嵌套 map 要逐层初始化。例如 map[string]map[string]int 的外层不为 nil，也不代表 inner[key] 已经可写；取出内层后仍要判断并 make。若值是切片，m[key] = append(m[key], item) 的便利性来自 nil slice 可以 append，不能套用到 nil map 的元素赋值上。

四、几个容易混淆的边界

delete 和 range：对 nil map 调用 delete 不会 panic，遍历也只是零次迭代；这只说明这些操作不需要新增元素，不表示 map 已可写。

并发场景：初始化解决的是 nil map，不解决并发读写。多个 goroutine 同时读写同一个 map 仍需要同步，否则可能出现并发 map 读写错误。应先明确初始化时机，再用互斥锁或其他并发设计保护访问。

最后的检查清单：看到 map 写入时，先问它是否可能来自零值结构体、未赋值返回值或 nil 参数；看到读取 0 时，使用 ok 区分缺失键；看到嵌套 map 时，逐层检查；看到计数 map 时，不要因为 nil slice 的 append 经验而省略 map 初始化。

相关问题

nil map 调用 len 会 panic 吗？

不会，len(nilMap) 返回 0。它只是读取当前长度，不能证明 map 后续可以写入。

把 nil map 传给只读函数安全吗？

通常安全，只要函数不执行元素赋值。读取、len、range、delete 都不会因为 map 为 nil 而触发这类写入 panic。

事实依据：Go 语言规范的 Map types 与 Go 官方博客的 maps 说明。文章中的代码和图示是原创解释，不代表在本机执行所得的截图或运行证据。