嵌套 map 的标准写法是 map[string]map[string]interface{}，但必须手动初始化内层 map
Go 不会自动帮你创建内层 map，直接对未初始化的嵌套 map 赋值会 panic：panic: assignment to entry in nil map。比如 m["a"]["b"] = 1 在 m["a"] 还是 nil 时就炸了。
- 先检查外层 key 是否存在，不存在则
m[key] = make(map[string]interface{}) - 再对内层 map 赋值：
m[key]["inner"] = value - 如果层级更深（如三层），每一层都要单独
make，不能链式调用 interface{}是常见选择，但类型越具体越好——比如确定内层全是string，就用map[string]map[string]string，能避免运行时类型断言
用结构体替代嵌套 map 更安全、更易维护
嵌套 map 看似灵活，实际在字段固定、语义明确时反而增加出错概率：拼错 key 名、漏判 nil、类型混乱都很难被编译器捕获。
- 例如表示用户配置的多级开关：
map[string]map[string]bool不如定义type Config struct { Features map[string]bool; Limits map[string]int } - 结构体字段可导出、可加注释、可嵌套、可实现方法，IDE 和
go vet都能更好支持 - 如果真需要动态 key（比如解析未知 JSON），优先考虑
json.RawMessage或map[string]json.RawMessage延迟解析，而不是全用interface{}
map[string]map[string]interface{} 的性能和并发问题很现实
嵌套 map 在高并发读写下极易出错——Go 的 map 本身不是线程安全的，两层嵌套意味着要同时锁住外层和内层，极易死锁或遗漏。
- 别试图用一个
sync.RWMutex锁整个外层 map：写内层时会阻塞所有读，性能差 - 也不建议为每个内层 map 单独配一把锁：锁数量爆炸，内存和管理成本高
- 更可行的方案是用
sync.Map替代外层（仅适用于读多写少），或改用单层 flat map：map[string]interface{}，用"user:settings:timeout"这类拼接 key - 如果必须嵌套且需并发安全，封装成一个带锁的结构体，统一控制访问路径
JSON 反序列化时嵌套 map 容易掉进类型陷阱
用 json.Unmarshal([]byte, &v) 解到 map[string]interface{} 后，里面的数字默认是 float64，不是 int；布尔值是 bool，但嵌套深了容易忘记类型断言。
- 例如
v["data"].(map[string]interface{})["count"]实际是float64，直接转int会丢精度 - 更好的做法是定义目标结构体，让
json包自动转换：type Resp struct { Data DataItem }，避免层层.([]interface{})和.(map[string]interface{}) - 如果必须用泛型 map，至少封装一个辅助函数做类型提取：
GetInt(m, "count")内部处理float64到int的安全转换
