go中map未初始化就写入会panic；读key必须用v, ok := m["key"]判断存在性；遍历顺序随机，不可依赖；并发读写需加锁。
map声明不初始化就写入，直接panic
Go里var m map[string]int只是声明了一个nil指针，不是空字典。这时候执行m["a"] = 1会立刻崩溃，报错assignment to entry in nil map。
- 必须用
make(map[string]int)或字面量map[string]int{"x": 1}初始化后才能写 - 结构体里嵌套
map字段也一样：只声明不make，调用方法时一写就崩 - 测试时容易漏掉——因为读
m["x"]返回零值不会panic，掩盖了未初始化问题
读key存在性不能只靠单返回值
v := m["key"]永远不报错，但你无法区分“key真不存在”和“key存在但值恰好是零值（比如0、""、false）”。这是新手高频翻车点。
- 务必用双返回值：
v, ok := m["key"]，靠ok判断真实存在性 - 配置解析、API响应解包、缓存查询等场景尤其关键——把
0当成默认值还是缺失值，语义完全不同 - 漏掉
ok检查，可能让bug潜伏数月，直到某次数据恰好为零值才暴露
for range遍历顺序每次都不一样
Go从1.0开始就**故意打乱**map遍历顺序，不是bug，是防你依赖它。所以for k, v := range m输出顺序每次运行都可能不同。
- 不要在日志、调试输出、单元测试断言里假设顺序固定
- 需要有序遍历时，先收集所有key：
keys := make([]string, 0, len(m)); for k := range m { keys = append(keys, k) }，再sort.Strings(keys) - 别被本地多次运行结果一致骗到——那是哈希种子巧合，CI环境或升级Go版本后很可能突变
并发读写map会随机panic
原生map不是线程安全的。两个goroutine一个写、一个读，大概率触发fatal error: concurrent map read and map write。
- 通用解法是加
sync.RWMutex：读前RLock()，写前Lock() -
sync.Map只适合读远多于写的场景（如配置缓存），且不支持len()、遍历接口不统一，别盲目替换 - 如果数据能预知范围，用切片+索引代替map，性能更高也天然无并发问题
最麻烦的从来不是语法怎么写，而是那些“看起来能跑通”的写法——比如没检查ok、没加锁、依赖遍历顺序。它们不会立刻报错，但会在某个流量高峰、某次部署、某条特殊数据进来时突然爆发。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
