预分配容量可显著提升map性能：明确元素数时用make(map[k]v, hint)避免多次扩容，hint≤8时分配1个bucket，>8时自动取整到2的幂；小map建议设64或128。
预分配容量：最简单却常被跳过的提速手段
Go 的 map 不是“用多少分多少”，而是动态扩容——每次元素数超过负载因子（≈6.5）就翻倍重建哈希表，迁移所有键值对。10 万次写入若从空 map 开始，可能触发 17 次扩容，每次都要 O(n) 时间重哈希，实测耗时可高出 40% 以上。
- 明确知道大概要存多少 key？直接
make(map[string]int, 100000)。hint 是“期望元素总数”，不是 bucket 数，运行时会自动向上取整到最近的 2 的幂（如 1000 → 实际约 2048 槽位） - hint ≤ 8 时，Go 直接分配 1 个 bucket（8 槽）；hint > 8 时才开始计算桶数，所以小 map 也建议设个 64 或 128，省掉首次扩容
- 别设过大（比如
make(map[int]string, 1e7)），内存浪费可控，但比反复扩容更稳；若规模波动大，先统计再建 map，或分批 +clear()复用（Go 1.21+）
并发写入：别迷信 sync.Map，先看读写比例
原生 map 并发读写必 panic：“fatal error: concurrent map read and map write”。但选错并发方案反而拖慢性能——sync.Map 在“一写多读、key 基本不更新”的缓存场景才明显占优；若高频写不同 key，它内部 dirty map 膨胀快，性能可能不如带 sync.RWMutex 的普通 map。
- 写频繁（如日志聚合、实时计数）→ 用
sync.RWMutex包一层普通 map，写锁粒度可控，且避免sync.Map的额外指针跳转开销 - 读远多于写，且 key 生命周期长 →
sync.Map合理，注意用Store()/Load()，别混用原生 map 操作 - 超高竞争（如 5w goroutine 写同一 key）→ 考虑分片 map（sharded map），按 key 哈希取模分散到多个子 map + 独立锁，降低锁争用
Key 类型选择：影响哈希速度和内存局部性
Key 不只是“能比较就行”，它直接决定哈希计算快慢、是否触发 GC 扫描、甚至 cache line 利用率。字符串越长，哈希越慢；结构体含指针或切片，哈希需递归遍历；而 int64 或短 string（≤8 字节）几乎零拷贝。
