Go map 是哈希表，底层为开放寻址哈希表（带溢出桶的数组结构），非有序、不支持并发读写，需手动加锁；key 必须为可比较类型，初始化须用 make 或字面量；扩容渐进式，性能受负载因子和哈希均匀性影响。
Go map 是哈希表，不是红黑树或链表
Go 的 map 底层是开放寻址哈希表（带溢出桶的数组结构），不是有序结构，也不保证插入顺序。它不支持并发读写，这点和 C++ std::unordered_map 或 Java HashMap 类似，但比 Python dict（CPython 3.7+ 有序）更“裸”——语言层不承诺任何顺序保障。
常见错误现象：fatal error: concurrent map writes 或随机 panic，往往是因为多个 goroutine 直接对同一个 map 做 write（哪怕只是 map[k] = v）而没加锁。
- 使用场景：高频读、中低频写、键类型支持 == 和 !=（即可比较类型），如
string、int、struct{}；不能用 slice、map、func 作 key -
map初始化必须用make或字面量，var m map[string]int得到的是 nil map，对它读会返回零值，写则 panic：panic: assignment to entry in nil map - 性能影响：负载因子（元素数 / 桶数）超过 6.5 时会触发扩容，扩容是渐进式（分多次 rehash），但单次
put可能触发迁移逻辑，延迟略高
hmap 结构体里真正干活的是 buckets 和 oldbuckets
Go 运行时源码中（src/runtime/map.go），hmap 是 map 的运行时表示。它不直接存键值对，而是通过 buckets（主桶数组）和 oldbuckets（扩容中旧桶）两级指针管理数据。
关键点：buckets 是一个指向 bmap 类型数组的指针，每个 bmap 实际是一个固定大小（默认 8 个槽位）的结构体，里面包含 top hash 数组、key 数组、value 数组、overflow 指针——不是链表节点，而是指向另一个 bmap 的指针，形成溢出链。
立即学习“go语言免费学习笔记（深入）”；
- top hash 用于快速过滤：取 key 哈希高 8 位，先比这个再比全哈希，避免无效内存访问
- 扩容时不会一次性搬完所有数据，而是每次增/删/查都顺手迁移一个 bucket（叫 “incremental doubling”），所以
len(m)返回的是准确总数，但底层可能横跨新旧两套桶 - 如果你用
unsafe强制访问hmap字段（比如调试或写测试），注意buckets和oldbuckets都是unsafe.Pointer，且字段名在不同 Go 版本中可能重命名（如 Go 1.22 改了部分字段名）
mapassign 和 mapaccess1 的调用路径决定性能敏感点
每次 m[k] = v 走的是 mapassign，每次 v := m[k]（非空检查）走的是 mapaccess1。这两个函数都在 runtime 中用汇编+Go 混合实现，核心逻辑是：计算 hash → 定位 bucket → 线性探测（最多 8 次）→ 找空槽或匹配 key。
容易踩的坑：map[string]struct{} 看似省内存，但 struct{} 占 0 字节，实际每个 value 槽仍占 1 字节对齐空间；更省的方式是用 map[string]bool（语义清晰）或自己封装 Set（用 map[string]struct{} + 方法），但别指望靠它“优化”内存——GC 不会因此变快。
- key 类型越小、哈希越均匀，冲突越少，线性探测步数越低；自定义 struct 作 key 时，确保字段顺序和类型稳定（否则序列化/反序列化后 hash 不一致）
- 如果频繁遍历 map 全量数据，不要用
for k := range m后再m[k]查值——这是二次哈希；直接for k, v := range m - benchmark 时注意：空 map 和满 map 的平均查找成本差 3–4 倍；用
go tool trace可看到runtime.mapassign的调用耗时分布
sync.Map 适合读多写少，但别把它当通用 map 替代品
sync.Map 是为「高并发读 + 偶尔写」设计的，内部用 read map（原子操作）+ dirty map（带互斥锁）双层结构。它的 Load 几乎无锁，Store 在 read map 命中且未被删除时也免锁；但一旦触发升级（dirty map 为空时首次写），就要锁住整个 dirty map 并拷贝 read map 进来。
常见误用：把 sync.Map 当成线程安全的通用容器塞进全局变量，结果发现写吞吐暴跌、GC 压力变大——因为它的内存占用是普通 map 的 2–3 倍，且不支持 len()、range 等原生操作。
- 适用场景：配置缓存、连接池元信息、服务发现中的 endpoint 映射；不适合做计数器（
Inc需要 CAS，sync.Map不提供）、也不适合做需要遍历或排序的集合 - 参数差异：它只接受 interface{} 作 key/value，没有泛型，类型断言开销不可忽略；Go 1.21+ 推荐优先用
sync.Map[K, V]（带泛型的包装） - 兼容性影响：Go 1.19 开始
sync.Map内部实现从 RWMutex 切换为更细粒度的锁，但对外行为不变；不过Range回调中禁止修改 map，否则行为未定义
