Go map非线程安全，需用sync.Map或封装加锁；声明后必须make初始化；判断key存在须用v,ok双赋值；预估容量避免扩容；key宜用简单类型，value大时存指针；迭代顺序随机不可依赖。
Go 语言的 map 不是线程安全的，多 goroutine 并发读写会直接 panic（fatal error: concurrent map read and map write），这点必须在设计初期就明确——不是“能不能用”，而是“怎么安全地用”。
声明和初始化：别漏掉 make
Go 的 map 是引用类型，声明后必须初始化才能使用，否则 nil map 写入会 panic，读取虽不 panic 但返回零值，容易埋下隐性 bug。
正确方式只有两种：
-
var m map[string]int声明后，必须跟m = make(map[string]int)或m = make(map[string]int, 16)（第二个参数是预分配 bucket 数，非必需但可减少扩容） - 直接短变量声明：
m := map[string]int{"a": 1, "b": 2}，此时已初始化，可立即读写
错误示范：var m map[string]int; m["k"] = 1 → panic: assignment to entry in nil map
立即学习“go语言免费学习笔记（深入）”；
判断 key 是否存在：用双赋值，别只靠零值
map 查找返回两个值：value 和 bool。仅靠 value 判断（比如 v := m["k"]; if v != 0 { ... }）会误判：当 value 类型是 int、string 等，零值本身合法（如 m["count"] 初始就是 0），无法区分“key 不存在”和“key 存在但值为零”。
必须用双赋值：
v, ok := m["k"]
if ok {
// key 存在，v 是对应值
} else {
// key 不存在
}
这个 ok 是唯一可靠的判断依据。
并发安全：别自己加锁，优先用 sync.Map 或封装
标准 map 并发读写崩溃是确定行为，不能靠“概率低”侥幸。常见错误是只对写加锁、放任并发读——依然不安全。
选择方案取决于场景：
- 读多写少、key 固定或增长缓慢：用
sync.Map，它内部做了分段锁 + 只读缓存优化，比全局sync.RWMutex+ 普通map更高效 - 需要遍历、删除、或复杂逻辑（如原子 compare-and-swap）：自己封装
struct+sync.RWMutex，把 map 包进去，所有操作走方法入口 - 高频写、低延迟要求极高：考虑分片 map（sharded map），手动按 key hash 分到多个带锁子 map，但增加复杂度，多数场景没必要
注意：sync.Map 的 LoadOrStore、Range 等方法是原子的，但它的遍历（Range）不保证看到全部最新写入——这是其设计取舍，文档明确说明。
内存与性能：避免频繁扩容和指针逃逸
map 底层是哈希表，扩容代价高（rehash 所有元素）。若能预估大小，初始化时传入容量（make(map[int]string, 1000)）可避免多次扩容。
另一个易忽略点：map 的 key/value 若是大结构体（如含 slice、map、指针字段），值拷贝开销大；更严重的是，若 value 是指针类型（如 *User），且该 struct 在栈上分配后被 map 持有，会导致逃逸到堆，增加 GC 压力。
建议：
- key 尽量用简单类型（
int,string,[8]byte） - value 大于 128 字节时，考虑存指针而非值（但需确认生命周期）
- 避免在 hot path 上反复
make新 map，复用或预分配
map 的迭代顺序是随机的，每次运行都不同，切勿依赖遍历顺序——这既是安全特性，也是防止程序意外依赖未定义行为的保护机制。
