再见，Go map 的渐进式扩容！Go 1.28 将迎来 maps.Grow
内容提要
Go团队接受maps.Grow提案，将在Go 1.28为已有map提供主动预扩容能力。maps.Grow(m,n)为map预留至少n个新增元素空间，是尽力而为的容量提示，不暴露真实容量；n为负或nil map且n>0会panic。maps.Copy也将自动预扩容，源map更大时先扩容再复制。基准测试显示，大map批量复制耗时最多降低约57%，内存和分配次数约减半。该API适用于HTTP Header合并、ReverseProxy等场景。
延伸解读
为什么已有 map 需要主动预扩容
文章指出，make 的容量提示只能在创建 map 时使用，而实际代码中常遇到目标 map 已由调用方持有、无法重新创建的情况。此时若批量写入大量元素，只能接受运行时渐进式扩容，或自行重新分配并复制旧数据。maps.Grow 正是为这种“原地修改已有 map”的场景补上主动预留空间的能力，适用于 HTTP Header 合并、ReverseProxy 等真实用例。
Grow 的语义边界：提示而非保证
maps.Grow(m, n) 中的 n 表示新增元素数量，而非目标总容量，语义接近 Rust 的 reserve(additional)。它不会缩小 map，也不暴露真实容量，且官方明确这只是尽力而为的提示，不保证后续绝不扩容。n 为负数，或 m 为 nil 且 n>0 时会 panic；Grow(nil, 0) 则不会。这些边界与向 nil map 写入的行为保持一致，使用时需注意。
maps.Copy 自动预扩容的收益与条件
除新增 Grow 外，maps.Copy 也获得自动预扩容：当源 map 元素数大于目标 map 时，先按 len(src)-len(dst) 扩容再复制，避免 Key 重叠导致过度分配；源 map 很小时则跳过预扩容。基准测试显示，大 map 批量复制耗时最多降低约 57%，内存和分配次数约减半；而两 map 大小相同或 Key 完全相同时性能基本不变，说明优化只针对真正存在扩容需求的场景。
设计取舍：不提供 map 容量查询
文章回顾，社区曾讨论为 map 增加类似 slice 的 cap 能力，但相关提案未被接受，原因之一是 map 容量无法保证后续写入不扩容。maps.Grow 因此选择只提供表达扩容意图的 API，具体分配多少内存、如何组织底层存储仍由 Runtime 决定。这也意味着 Grow 不能替代 make：map 尚未创建时仍应优先使用 make 的容量提示，Grow 只用于已存在 map 的原地批量写入。
Q&A
Go 1.28 的 maps.Grow 是做什么的？
maps.Grow(m, n) 为已存在的 map 预留至少 n 个新增元素的空间，是尽力而为的容量提示，不暴露真实容量，也不保证后续绝不扩容。
为什么已有的 map 需要主动预扩容？
make 的容量提示只能在创建 map 时使用；对于已存在且不能替换的 map（如第三方持有、HTTP Header），批量写入时只能接受运行时渐进式扩容或重新分配复制，带来额外开销。
maps.Grow 的参数 n 是总容量还是新增元素数？
n 表示新增元素数量，而非 map 的目标总容量。例如已有 2 个元素时调用 maps.Grow(m, 1000)，相当于为已有元素之外的 1000 个新增元素预留空间。
maps.Grow 在什么情况下会 panic？
n 为负数时会 panic；m 是 nil map 且 n > 0 时也会 panic。但 Grow(nilMap, 0) 不会因 nil map 而 panic。
maps.Copy 这次有什么优化？
maps.Copy 增加了自动预扩容逻辑：当源 map 元素数量大于目标 map 时，先为目标 map 扩容再复制；对于很小的 map（源元素数不超过一个 map Group 容量）会跳过预扩容，避免额外开销。
maps.Grow 和 maps.Copy 优化能带来多少性能提升？
基准测试显示，在大 map 批量复制场景中耗时最多降低约 57%（如空 map 复制 64 个元素从 4.899 μs 降至 2.101 μs），内存使用量和分配次数约减少 50%；不需要预扩容的场景性能基本不变。
maps.Grow 适用于哪些实际场景？
适用于目标 map 已存在且需原地批量写入的场景，如 HTTP Header 合并、ReverseProxy 合并上游响应 Header、CGI 响应头写入已有 Header map，以及 Honeycomb libhoney-go 等批量数据导入场景。
