直接回答：Go 1.24 把 map 的底层从传统的“桶链 + tophash 字节”hmap 换成 Google 的 Swiss Table 设计：每个桶（group）配一个 8 字节的控制字，每字节存一个槽位的 7 位哈希指纹（h2），查询时用 SIMD 一条指令并行比对 8 个指纹，不匹配直接跳过整组，省掉逐个键的比较与缓存行浪费；删除用 tombstone 标记，扩容改为增量式的目录分裂（extendible hashing 思路），大 map 扩容更平滑。
展开解析：收益：官方数据访问性能提升明显（尤其 miss 场景与大 map），内存占用也有所下降；控制字与数据分离的布局更缓存友好。对外行为不变的承诺被严格保持：遍历仍随机、仍不可并发写、容量提示仍有效——这正是内部重写能静默上线的前提。顺带的重要变化：map 的预分配提示更有效了，增量扩容消除了大 map 一次性搬桶的延迟尖峰。关联生态：Swiss Table 思想源自 Abseil 的 flat_hash_map，Rust 标准库的 HashMap（hashbrown）更早采用；Go 这次跟进属于成熟设计的多语言验证。对开发者的实践影响：无需改代码，但自定义哈希表的需求（为性能手写开放寻址表）进一步减少；做性能敏感系统时了解“控制字 + SIMD 指纹”结构有助于理解 cache 行为。排查类问题仍是老三样：并发读写 fatal error、key 类型含 NaN 的怪异行为、map 只增不缩的内存保留。
追问方向：Swiss Table 的删除为什么用 tombstone？map 为什么不做缩容？
（约 470 字）