Go map 作为缓存索引时怎样避免 nil map 写入

把 map 当作缓存索引时，最容易踩到的坑不是读取，而是第一次写入：var byKey map[string]Item 得到的是 nil map，读取不存在的键会返回零值，但执行 byKey[key] = item 会触发 assignment to entry in nil map。处理原则很简单：所有写入路径都要经过 make 初始化；读取路径则用双值返回区分“未命中”和“命中了一个零值”。

先把 nil map 的读写语义分开

Go 规范把未初始化 map 的值定义为 nil。对 nil map 做索引读取时，如果键不存在，结果是元素类型的零值；对它调用 len 会得到 0，range 不会产生元素，delete 也不会报错。真正危险的边界只有写入元素。先把这条边界记住，排查缓存初始化问题会快很多：

创建缓存索引时直接用 make

如果缓存对象有明确的创建入口，优先在构造函数中初始化。容量参数只是容量提示，不限制 map 的最终大小；它表达的是“预计会放入多少项”，不是固定上限。

package cache

type Item struct {
    Value string
}

type Index struct {
    byKey map[string]Item
}

func NewIndex(capacity int) *Index {
    // 创建入口完成初始化，后续 Set 不必重复判断 nil。
    if capacity 

这种写法的边界是：调用方不能直接写 Index{} 后再调用 Set。如果类型会被配置解码、测试夹具或其他包用零值构造，就需要在写入方法内部再加一道惰性初始化。

让缓存索引的零值也能安全写入

惰性初始化的关键不是每次都重新 make，而是只在字段仍为 nil 时初始化一次。把判断集中到私有方法，能避免多个写入口各自遗漏。

func (i *Index) ensure() {
    // 只有零值 Index 才需要分配；已有数据不会被覆盖。
    if i.byKey == nil {
        i.byKey = make(map[string]Item)
    }
}

func (i *Index) Set(key string, item Item) {
    // 所有写入统一先经过初始化边界。
    i.ensure()
    i.byKey[key] = item
}

func (i *Index) Get(key string) (Item, bool) {
    // ok 表示键是否存在，不要用 Item 的零值代替命中判断。
    item, ok := i.byKey[key]
    return item, ok
}

注意，这个示例只解决 nil map 的初始化问题，不自动解决并发读写。多个 goroutine 同时访问同一个索引时，还要在外层设计互斥锁或使用适合场景的并发结构；不要把“已初始化”误当成“并发安全”。

用双值读取做回归检查

缓存通常允许 value 的零值存在，例如 Item{} 也可能是有效记录。因此回归测试至少要覆盖零值对象、未命中和写入后命中三个状态：

func checkIndex() {
    var index Index // 故意使用零值结构，验证 Set 的惰性初始化。
    index.Set("user:1", Item{})

    if _, ok := index.Get("missing"); ok {
        panic("unexpected cache hit") // 未写入的键必须是未命中。
    }
    if _, ok := index.Get("user:1"); !ok {
        panic("cache entry was lost") // value 为零值也不影响键存在判断。
    }
}

上线前可以按这张清单检查：写入方法是否覆盖零值对象；是否有直接给 map 元素赋值的旁路；读取是否使用 ok；是否把容量参数误当成上限；若存在并发调用，是否另有同步设计。

常见问题

nil map 能不能读取？

可以。不存在的键返回元素类型零值，但这不代表键真的存在。

为什么 nil map 的 delete 不 panic？

delete 对不存在的键本来就是无操作，所以清理 nil map 不会产生写入分配。

用 map 字面量能避免这个问题吗？

可以，map[string]Item{} 会得到可写的空 map；在需要动态容量时使用 make 更清楚。