Go nil map 为什么读取正常但赋值会 panic

Go 的 map 零值是 nil。读取 nil map 中不存在的键会得到元素类型的零值，使用两值形式时 ok 为 false；但向 nil map 写入元素会触发 panic。读操作不需要先创建可写容器，写操作则要求 map 已用 make 或字面量初始化。

因此“读取正常”不能证明它已经可写。若只是 map 里没有数据，要分清它是 nil，还是已经初始化但长度为 0 的空 map。后者可以直接赋值，前者不行。

Go 官方地址：https://go.dev/

页面能显示空状态，不等于保存状态已经准备好

考虑后端用 map 保存表单字段错误：页面第一次打开，读取 errors["email"] 得到空字符串，于是显示为没有错误；用户提交后，后端尝试给同一个 map 写入提示，才出现 panic。我处理这类代码时，更倾向于先明确写入方法的初始化责任，而不是在所有读取位置都加一层 nil 判断。

这是一个用于讲解的表单状态场景，不是事故实测记录。下面示例均未执行，预期值来自 Go 语言规则，读者可在独立程序中自行观察。

package main

import "fmt"

func main() {
    var fieldErrors map[string]string
    value, ok := fieldErrors["email"]
    // 预期为空字符串、false、0、true；不会自动创建 map。
    fmt.Printf("value=%q exists=%t len=%d nil=%t\n",
        value, ok, len(fieldErrors), fieldErrors == nil)

    // 这里仅以注释展示故障点：解除注释会向 nil map 写入。
    // fieldErrors["email"] = "请填写邮箱"
}

空字符串可能是缺失键的零值，也可能是人为存入的空字符串。需要区分时检查 ok。注意 ok 只描述这个键是否存在，不是在告诉你整张 map 是否 nil；判断容器本身仍要使用与 nil 的比较。

nil map 与已初始化空 map 的差异

我会避免用 len(m)==0 作为“需要初始化”的条件。它会把正常的空 map 也重新创建，掩盖代码的真实意图。写入前需要判断的是 m==nil；已有内容时则保留原来的 map。

让状态对象负责自己的写入初始化

如果希望结构体零值就能使用，可把初始化放进指针接收者的方法。这样页面读取仍然简单，保存方法则保证字段 map 已可写：

package main

import (
    "fmt"
    "strings"
)

type FormState struct {
    Errors map[string]string
}

func (s *FormState) SetError(field, message string) error {
    // nil 接收者与 nil map 是两类问题，这里分别处理。
    if s == nil {
        return fmt.Errorf("表单状态对象不能为空")
    }
    field = strings.TrimSpace(field)
    if field == "" {
        return fmt.Errorf("字段名不能为空")
    }
    if s.Errors == nil {
        s.Errors = make(map[string]string)
    }
    s.Errors[field] = message
    return nil
}

func main() {
    var state FormState
    if err := state.SetError("email", "请填写邮箱"); err != nil {
        fmt.Println(err)
        return
    }
    // map 已初始化，字段提示应能保存并读回。
    fmt.Println(state.Errors["email"])
}

指针接收者让方法可以更新结构体字段本身。若项目全部通过构造函数创建对象，也可以在构造时初始化；但只要仍允许 var state FormState、结构体字面量或其他创建路径，就要决定这些路径是否同样应该可写。

不要把 recover 当成初始化策略。它最多在特定边界恢复控制，不能自动补回已经中断的字段保存逻辑。对可预期的容器状态，直接在负责写入的位置初始化更容易理解。

函数内部 make 后，为什么调用方还是 nil

map 参数按值传递。传入非 nil map 后，函数可修改共享映射的元素；但把参数重新绑定到一张新 map，不会替调用方变量重新赋值。若函数允许接收 nil，应显式返回新 map，让调用方接住：

// PutError 返回可写 map，调用方必须接收返回值。
func PutError(m map[string]string, field, message string) map[string]string {
    if m == nil {
        m = make(map[string]string)
    }
    m[field] = message
    return m
}

// 以下语句可放入调用方函数内。
// var errorsByField map[string]string
// errorsByField = PutError(errorsByField, "email", "请填写邮箱")

我更喜欢把返回契约写在函数名附近的注释里，避免读者误以为只调用 PutError 就能修复外部 nil 变量。如果对象拥有 map，用上一节的状态方法通常更贴合这个归属。

外层 map 初始化，不会自动初始化内层 map

按页面分组保存字段提示时，类型可能变成 map[string]map[string]string。外层 make 只准备外层；某个分组不存在时，读取到的内层 map 仍是 nil。

// 此片段放在函数内；外层与目标分组分别初始化。
groups := make(map[string]map[string]string)
if groups["profile"] == nil {
    groups["profile"] = make(map[string]string)
}
groups["profile"]["email"] = "请填写邮箱"

这个分层责任与界面结构可以保持一致：页面或表单拥有外层集合，分组拥有内层字段提示。清空字段提示时，应明确是删除元素还是把整个 map 置为 nil；置 nil 后下一次写入仍要重新准备。

页面反馈和并发边界也要明确

后端保存提示成功后，前端应把它放到对应字段附近，并通过可关联的文字让辅助技术识别，不能只靠边框颜色。没有字段错误只说明当前 map 没记录提示，不一定等于整份输入已经合法；校验结论应由业务规则给出。

初始化不会解决并发访问。示例假设状态由一个执行路径独占；多 goroutine 共享并修改普通 map 时，应另行设计同步或所有权。不要把“加一个 nil 判断”误认为已经让整个状态组件并发安全。

new(map[string]string) 能直接得到可写 map 吗？

不能。它得到指向 map 零值变量的指针，解引用后的 map 仍为 nil。需要可写映射时，用 make 或非 nil 的 map 字面量。

map[string]string{} 与 make 的空 map 都能写吗？

都能。选择取决于是否需要同时写入初始键值，以及代码的表达习惯。

只读参数能接受 nil map 吗？

如果接口约定允许，读取、len 和遍历空集合的逻辑可以利用零值语义。但不要把这个只读契约自动推广到写入函数。

规则参见 Go 语言规范 map 类型及 Go 官方 map 说明。