Go map扩容采用渐进式搬迁，每次读写操作最多迁移两个bucket以摊平停顿，但会引发延迟毛刺、内存虚高及伪共享等问题；预设容量是最有效的规避方式。
Go map 扩容本身不阻塞主线程，但搬迁策略会把 rehash 压力摊到后续每一次读写操作上，对延迟敏感服务（如微服务响应、实时风控）可能造成不可预测的毛刺。
mapassign 和 mapaccess 时都会触发搬迁
只要 map 正在扩容（h.oldbuckets != nil），每次调用 mapassign 或 mapaccess1 都会顺带搬 1–2 个 bucket：
- 先搬「当前 key 所属的旧 bucket」——保证这次操作能落到新结构里
- 再按
h.nevacuate指针推进，搬下一个未搬迁的旧 bucket（最多一个） - 这意味着一次简单赋值
m[k] = v可能隐式执行数百次哈希计算 + 内存拷贝，尤其当 bucket 里有大量 key/value 时
渐进式搬迁不等于低开销，而是“可预期的抖动”
它把 O(n) 的一次性成本拆成小块，但总工作量不变，且存在几个放大延迟的细节：
- 搬迁过程中要同时维护
buckets和oldbuckets两套内存结构，GC 扫描压力翻倍 - 若 map 长时间只读不写（比如配置缓存），
nevacuate停滞，oldbuckets一直不释放，内存持续虚高 - 并发场景下，多个 goroutine 可能同时触发对同一旧 bucket 的搬迁检查，产生伪共享和锁竞争（
h.flags & hashWriting检查虽轻，但高频时仍可观）
sameSizeGrow 场景下搬迁更隐蔽但更危险
当发生等量扩容（sameSizeGrow）时，B 不变、主 bucket 数不变，只新增溢出桶。这种搬迁容易被忽略，但问题更棘手：
- 它不改变地址空间大小，
pprof中hashGrow调用次数少，但overflow分配陡增 - 搬迁只针对特定 hash 高位的 key，导致部分 bucket 搬得快、部分极慢，负载不均加剧
- 如果 key 哈希分布极端倾斜（例如大量字符串前缀相同），可能反复触发 sameSizeGrow，形成“扩容-溢出-再扩容”循环
真正影响实时性的不是“扩不扩容”，而是“谁来搬、什么时候搬、搬多少”。预分配足够容量（make(map[K]V, N) 中 N 按最大预期向上取整到 2 的幂）仍是规避这类抖动最直接有效的方式。否则，就得靠 runtime.ReadMemStats 监控 Mallocs 和 NextGC，或用 go tool trace 抓取具体哪次 mapassign 触发了异常耗时搬迁。
