Go 禁止对 map 元素取地址（如 &m[key]），因其底层无稳定内存布局，易产生悬垂指针；而 slice 元素可安全取地址，因扩容时旧底层数组仍有效，原有指针保持合法。这是 Go 内存安全设计的关键体现。
go 禁止对 map 元素取地址（如 `&m[key]`），因其底层无稳定内存布局，易产生悬垂指针；而 slice 元素可安全取地址，因扩容时旧底层数组仍有效，原有指针保持合法。这是 go 内存安全设计的关键体现。
在 Go 的内存模型中，slice 和 map 的底层实现机制存在本质差异，这直接决定了它们对待“取地址”操作的安全性边界。
? Slice：视图 + 稳定底层数组（扩容不破坏旧指针）
Slice 是对底层数组的轻量视图（包含指针、长度、容量三元组）。当你对 slice 元素取地址（如 &s[i]），实际获取的是底层数组中对应元素的内存地址：
s := []int{10, 20, 30}
p := &s[1] // 合法：p 指向底层数组第 1 个元素（值为 20）
fmt.Println(*p) // 输出 20
关键在于：当 append 导致 slice 容量不足时，Go 会分配新数组、复制数据、更新 slice 的底层指针，但原数组不会被立即回收——只要仍有引用（如其他 slice 或显式保存的指针），它就继续存活：
a := []int{1, 2, 3}
addrBefore := uintptr(unsafe.Pointer(&a[2])) // 取 a[2] 地址
a = append(a, 4, 5) // 触发扩容（假设原 cap=3）
addrAfter := uintptr(unsafe.Pointer(&a[2])) // 注意：此时 a[2] 已在新数组中！
// ⚠️ 但注意：&a[2] 是新地址；而之前保存的 addrBefore 仍指向旧数组中的有效值（只要旧数组未被 GC 回收）
// 若你另有 slice b := a[:2]（截取前两元素），其底层仍可能指向旧数组
因此，&s[i] 的安全性不依赖于“该 slice 是否后续扩容”，而依赖于底层数组是否仍在生命周期内——Go 的垃圾收集器仅在确认无任何引用时才回收数组，故已有指针不会突然失效。
❌ Map：哈希表 + 动态重散列（无稳定地址语义）
Map 在 Go 中是哈希表实现，其底层存储由多个动态增长/收缩的桶（buckets）组成。键值对的物理位置随负载因子变化、触发 rehash 而完全重分布：
m := map[string]int{"abc": 123}
// p := &m["abc"] // 编译错误：cannot take the address of m["abc"]
编译器禁止此操作，根本原因不是“用户会困惑”，而是技术上无法保证地址有效性：
- 插入/删除操作可能触发 bucket 重组；
- 原键值对可能被迁移到全新内存地址，甚至跨内存页；
- 若允许 &m[k]，将不可避免地生成悬垂指针（dangling pointer），违反 Go “内存安全零容忍”原则（即：不提供导致未定义行为的语法糖）。
✅ 正确替代方案：若需间接访问 map 值，应存储指向结构体的指针：
type Record struct{ Value int } m := map[string]*Record{} m["abc"] = &Record{Value: 123} p := m["abc"] // 合法：p 是 *Record，其指向的对象生命周期由 GC 管理
? 总结：设计哲学的落地体现
| 特性 | Slice | Map |
|---|---|---|
| 底层结构 | 连续数组（view） | 哈希桶数组（dynamic hash table） |
| 地址稳定性 | ✅ 元素地址在数组存活期内有效 | ❌ 无稳定地址语义 |
| 扩容影响 | 新数组分配，旧数组仍可访问 | 键值对物理位置彻底重排 |
| 取地址许可 | ✅ &s[i] 合法且安全 | ❌ &m[k] 编译期禁止 |
| 安全基石 | GC 保障底层数组生命周期 | 编译器强制阻断不可靠地址操作 |
这种差异并非权衡取舍，而是 Go 将内存安全前置到编译阶段的典型实践：对 slice，信任开发者理解视图与数组的关系；对 map，则用语法硬性隔离风险，避免运行时难以调试的内存错误。理解这一点，是写出健壮、可维护 Go 代码的重要基础。
