go 的 map 是基于哈希表的开放寻址变种，通过哈希定位桶、tophash高位预筛、桶内线性探测及溢出链实现平均 o(1) 查找，不遍历全部键。
Go 的 map 不是红黑树、不是有序数组、也不是简单线性表——它就是哈希表，且是带桶分组 + 高位预筛 + 溢出链的开放寻址变种。平均 O(1) 查找不靠运气，靠结构设计。
为什么 map[key]value 查找不遍历全部键
因为根本没遍历。流程是：算哈希 → 取低 B 位得 bucket 索引 → 检查该 bucket 的 tophash 数组（8 个 uint8）是否匹配哈希高 8 位 → 只有匹配的位置才做完整 key 比较。
-
B是hmap.B字段，表示桶数组长度为2^B；索引计算用位与hash & (1，比取模快得多 -
tophash存的是哈希值高 8 位，不是完整哈希，作用是快速跳过整个 bucket（80%+ 场景下一次就命中或排除） - 一个 bucket 最多存 8 对键值，内存布局紧凑（key 连续、value 连续），无指针开销
- 即使
len(m) == 1000000，只要负载因子正常（Go 默认上限 ~6.5），绝大多数查找仍只访问 1 个 bucket + 最多 2 次 key 比较
map 扩容时为什么旧数据不立刻迁移
扩容不是“复制完再切换”，而是渐进式疏散（incremental evacuation），由 nevacuate 字段记录进度。每次读/写操作只顺手搬一个 bucket，避免 STW（Stop-The-World）卡顿。
- 新桶数组大小为旧的 2 倍（
B增 1），但旧桶数组（oldbuckets）暂不释放 - 访问某个 key 时，先按新桶数算索引；若对应新 bucket 为空，再按旧桶数算索引，从
oldbuckets中读并搬走 -
extra字段里存着溢出桶链表头，扩容时也需同步迁移，否则链断裂 - 并发写 map 触发 panic，不是因为扩容逻辑错，而是因为
flags里写了bucketShift状态位被多 goroutine 同时修改
为什么 string 作 key 很快，而 []byte 不行
因为 map 要求 key 类型必须可比较（== 可用），而切片（[]byte）不可比较 —— 编译直接报错：invalid operation: cannot compare []byte。
- 合法 key 类型：
int、string、struct{a,b int}（字段都可比较）、*T、func（仅 nil 可比）等 -
string的哈希函数是stringhash，专为短字符串优化，且底层用unsafe直接读内存，不额外分配 - 若真要用字节序列作 key，得转成
string（如string(b)）或封装为可比较 struct（如type Key struct{ data [32]byte }） - 自定义类型若含不可比较字段（如
map或slice），哪怕只读也不行 —— Go 在编译期静态检查，不运行时判
真正容易被忽略的点在于：哈希行为完全由类型决定，不是由用户控制；tophash 预筛和 bucket 容量硬限（8）共同压制了最坏情况，但一旦大量 key 哈希高位相同（比如全用 "a"、"aa"、"aaa" 这类短串），就会退化到桶内线性扫描 —— 此时性能看的不是 map 大小，而是那个 bucket 里实际塞了多少个。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
