Go嵌套map必须逐层make初始化，否则运行时panic；两层可用判断+make，三层以上推荐结构体或扁平key单层map。
Go里嵌套map必须逐层make，不能直接赋值
Go的map是引用类型，但不会自动初始化深层结构。写m["a"]["b"] = 1时，如果m["a"]还没被make过，运行时直接panic：panic: assignment to entry in nil map。这不是语法错误，编译能过，但一跑就崩。
常见错误场景：解析JSON、构建配置树、聚合统计时想“一口气”写多级键值。
- 必须先检查并初始化每一层：比如
m["a"]是nil，就得m["a"] = make(map[string]int) - 别用
var m map[string]map[string]int声明后直接访问——这只会得到一个nil顶层map - 如果层级固定（如两层），可以一次性
make第二层；如果动态深度，得用循环或递归
两层map最常用写法：先判断再创建
多数业务场景是两层，比如map[string]map[string]interface{}存分组数据。安全写法不是靠“运气”，而是显式兜底。
示例：给groups["users"]["alice"]赋值
立即学习“go语言免费学习笔记（深入）”；
if groups["users"] == nil {
groups["users"] = make(map[string]interface{})
}
groups["users"]["alice"] = "active"
也可以封装成小函数复用，但注意别为了“简洁”牺牲可读性——比如一行三重嵌套判断反而难调试。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要写
groups["users"]["alice"] = "active"前不检查groups["users"] -
groups["users"]可能是nil，也可能是其他类型（比如string），类型断言前要确认 - 如果频繁写入，把初始化逻辑提到循环外，避免重复
make
三层及以上建议用结构体替代
写到m["a"]["b"]["c"] = 1时，代码已经难读、难测、难维护。Go不是JavaScript，硬撑嵌套map会放大bug概率，比如拼错键名、漏初始化某一层、类型混用。
真实项目中，三层以上基本对应明确语义：用户→设备→传感器读数、服务→实例→指标。这时候该用结构体：
type SensorData struct {
UserID string
DeviceID string
Value float64
}
配合map[string]map[string]map[string]float64？不如用map[string]map[string]*SensorData，或者直接上map[string]map[string]map[string]*SensorData——但更推荐用扁平key（userID + "/" + deviceID + "/" + sensorName）配单层map，查起来快，没panic风险。
- 嵌套超过两层，性能没优势，反而增加GC压力和指针跳转开销
- JSON反序列化时，如果结构固定，直接用struct比手动解嵌套map靠谱得多
- 如果真需要动态深度，考虑用
map[string]interface{}配合json.Unmarshal，但要自己做类型校验
初始化时用字面量还是make？看是否带初始数据
空map必须用make；带初始键值对，可用字面量，但仅限第一层。
正确：
m := map[string]map[string]int{
"a": {"x": 1, "y": 2},
"b": {"z": 3},
}
错误（第二层不能混用字面量+nil）：
m := map[string]map[string]int{
"a": {"x": 1},
"b": nil, // 这里会编译失败：cannot use nil as map[string]int value in map literal
}
- 字面量只适合初始化已知全部键值的场景，动态增删必须靠
make+ 显式赋值 - 用字面量定义两层map时，所有子map都会被创建，哪怕某个子map为空（如
"c": {}），它也不是nil - 如果初始化后还要大量写入，字面量和
make性能差异可忽略，选可读性强的那个
make，以及panic报错时堆栈不一定指向问题源头。 
