当 Go 语言的 map 中存储的数据量非常大时，会发生哪些性能或行为上的变化？请从底层实现角度说明原因。

回答思路

1. 【回答框架 1】Go map 底层是哈希表，由 hmap 结构体管理，核心是 bucket 数组。每个 bucket 可存 8 个键值对，数据量大时冲突增多，链表或溢出桶变长，查找效率下降。
2. 【回答框架 2】当负载因子（元素数/bucket 数）超过 6.5 或溢出桶过多时，map 会触发扩容。扩容分为等量扩容和翻倍扩容，会重新哈希所有元素，导致瞬时性能下降和内存占用增加。
3. 【回答框架 3】数据量过大时，map 的遍历顺序不稳定，且并发读写会直接 panic，只能通过加锁或使用 sync.Map 解决。
4. 【回答框架 4】实际影响：内存开销增大，每个 bucket 固定占用 8 槽位，即使空槽也占用内存；GC 扫描成本随元素数增加而上升（Go 1.24 前 map 不参与 GC 扫描，但后续版本有优化）。
5. 【回答框架 5】应对策略：预估容量提前初始化、分片 map（如 16 个 map 分散读写）或改用并发安全的数据结构。
6. 【关键点 1】map 底层是哈希桶数组，每个桶存 8 对键值，溢出桶过多会降低查找性能。
7. 【关键点 2】负载因子超过 6.5 或溢出桶数量过多时触发扩容，扩容是重哈希过程，代价高昂。
8. 【关键点 3】map 并发读写会 panic，数据量大时需加锁或使用 sync.Map 分片。
9. 【关键点 4】内存槽位固定，空桶也占内存，数据量大时内存浪费明显。
10. 【易错点 1】认为 map 容量过大时直接 OOM 或崩溃，实际是渐进式扩容，但单次扩容可能造成停顿。
11. 【易错点 2】忽略提前初始化容量，导致频繁扩容，性能下降。
12. 【易错点 3】误以为 sync.Map 无条件优于加锁 map，实际上读多写少时才更优。