在 Go 语言里，map 类型本身是否具备并发安全性？如果多个 goroutine 同时读写同一个 map，会发生什么？
考察说明
考察对 Go 内建 map 并发安全性的理解及并发访问的正确处理方式。
回答思路
- 【回答框架 1】Go 的 map 类型不是线程安全的，官方明确不支持并发读写。当多个 goroutine 并发访问同一个 map，只要存在写操作，就可能触发运行时检测并导致程序崩溃，报错信息为 fatal error: concurrent map writes 或 concurrent map read and map write。
- 【回答框架 2】这种不安全性的根源在于 map 内部实现使用了哈希表和复杂的扩容逻辑，没有任何锁或原子操作保护整体结构。读操作在理论上可以并发，但一旦与写操作同时进行，就可能读到中间状态或破坏内部结构，因此不能依赖任何并发场景下的安全性。
- 【回答框架 3】为了保证并发安全，可以采取几种常见方案。第一种是使用互斥锁 sync.Mutex 或读写锁 sync.RWMutex 包裹所有对 map 的访问，写操作加写锁，读操作可以加读锁以提高并发度。第二种是使用 sync.Map，它针对读多写少、键值对长期存活、或不同 goroutine 操作不同键的场景做了优化，但它的内部实现基于无锁机制，并不适合所有场景。第三种是采用分片加锁（sharding）的方式，即把 map 分成多个小 map，每个小 map 配一把锁，以减少锁竞争。
- 【回答框架 4】选择哪种方案取决于具体场景。如果并发读写都很频繁，且键冲突概率高，加锁可能是最简单可靠的选择；如果读远多于写，sync.RWMutex 或 sync.Map 更合适；如果写操作集中在部分键，分片加锁可以提升性能。此外，Go 1.9 之后引入的 sync.Map 适合键值对变化较少或在不同 goroutine 间隔离访问的场景，并不适用于所有情况。
- 【关键点 1】Go map 非线程安全，并发读写会触发 panic 崩溃。
- 【关键点 2】可以使用互斥锁、读写锁、sync.Map 或分片加锁来保证并发安全。
- 【关键点 3】sync.Map 适合读多写少、键长期稳定或不同 goroutine 访问不同键的场景，不是万能方案。
- 【易错点 1】不要因为读写锁允许多个读并发，就认为 map 本身是安全的，必须显式加锁。
- 【易错点 2】sync.Map 并非在所有场景下都优于加锁，错误使用可能降低性能。
- 【易错点 3】并发场景下切勿使用普通 map 进行写入，即使暂时没有崩溃，也可能导致数据竞争和未定义行为。