复合类型：数组、切片与 map

复合类型：数组、切片与 map

如果说函数是 Go 程序的骨骼，那么数组、切片和 map 就是血肉。在实际项目中，超过 80% 的数据存储和处理都依赖这三种复合类型。它们看起来简单——"不就是数组和哈希表吗"——但正是这种看似简单的表面下，隐藏着内存布局、扩容策略和并发安全性方面的精密设计。

理解这些底层机制不是学术兴趣——它直接决定了你的程序是在 10ms 内响应还是 OOM 崩溃。本章将从日常使用出发，逐层揭示切片的 SliceHeader 结构、append 的扩容算法、map 的桶式哈希实现，以及这些设计选择带来的陷阱。

Level 1 · 你需要知道的

数组：固定长度的值类型

Go 的数组与大多数语言不同——它是值类型（value type），不是引用类型。数组的长度是类型的一部分：[3]int 和 [4]int 是完全不同的类型，不能互相赋值。

// 声明与初始化
var a [5]int                    // 零值：[0, 0, 0, 0, 0]
b := [3]int{1, 2, 3}           // 字面量初始化
c := [...]int{1, 2, 3, 4, 5}   // 编译器推断长度：[5]int
d := [5]int{0: 1, 4: 5}        // 索引初始化：[1, 0, 0, 0, 5]

// 数组是值类型——赋值会拷贝整个数组
x := [3]int{1, 2, 3}
y := x      // y 是 x 的完整拷贝
y[0] = 99   // 修改 y 不影响 x
fmt.Println(x[0]) // 1

为什么 Go 选择值语义的数组？ 这是一个刻意的设计决策。Ken Thompson 和 Rob Pike 认为引用语义的数组（如 Java 的数组）会导致共享状态带来的 bug 难以追踪。值语义使得数组的行为完全可预测——传递给函数时不会被意外修改（Robert Griesemer, "Go Data Structures", 2009）。

但这也意味着：大数组传参会有拷贝开销。对于大数组，应该传指针：

// 不推荐：每次调用拷贝 8MB
func process(data [1000000]int) { ... }

// 推荐：传指针，零拷贝
func process(data *[1000000]int) { ... }

// 更推荐：使用切片
func process(data []int) { ... }

数组的使用场景很有限——在实际代码中很少直接使用裸数组。它们主要出现在：

• 固定大小的缓冲区（如 [64]byte）
• 作为 map 的键（切片不能作为 map 键，但数组可以）
• 作为切片的底层存储

切片：动态数组的引用语义

切片（slice）是 Go 中最常用的数据结构。它是对底层数组的一个视图（view），提供动态大小和引用语义：

// 创建切片的几种方式
s1 := []int{1, 2, 3}           // 字面量
s2 := make([]int, 5)           // make(type, length)
s3 := make([]int, 3, 10)       // make(type, length, capacity)
s4 := s1[1:3]                  // 从已有切片/数组截取

// 切片的三要素
fmt.Println(len(s3))  // 3  — 当前元素数量
fmt.Println(cap(s3))  // 10 — 底层数组总容量

切片与数组的核心区别：

切片的基本操作

// 追加元素
s := []int{1, 2, 3}
s = append(s, 4)          // 追加单个元素
s = append(s, 5, 6, 7)    // 追加多个元素
s = append(s, []int{8, 9}...) // 追加另一个切片

// 删除元素（没有内置 delete 函数）
// 删除索引 i 处的元素
s = append(s[:i], s[i+1:]...)

// 插入元素
// 在索引 i 处插入 elem
s = append(s[:i], append([]int{elem}, s[i:]...)...)

// 拷贝
src := []int{1, 2, 3}
dst := make([]int, len(src))
copy(dst, src)  // 返回拷贝的元素数量

// 切片截取
s = []int{0, 1, 2, 3, 4, 5}
s[2:4]    // [2, 3]        — 从索引 2 到 3（不含 4）
s[:3]     // [0, 1, 2]     — 从头到索引 2
s[3:]     // [3, 4, 5]     — 从索引 3 到末尾
s[:]      // [0, 1, 2, 3, 4, 5] — 完整切片

nil 切片 vs 空切片

这是一个微妙但重要的区别：

var s1 []int          // nil 切片：s1 == nil, len=0, cap=0
s2 := []int{}         // 空切片：s2 != nil, len=0, cap=0
s3 := make([]int, 0)  // 空切片：s3 != nil, len=0, cap=0

// 在大多数操作中行为相同
len(s1) == len(s2)    // true, 都是 0
append(s1, 1)         // 可以正常工作
for _, v := range s1 {} // 可以正常遍历（0 次迭代）

// 区别主要体现在序列化
json.Marshal(s1)  // null
json.Marshal(s2)  // []

最佳实践：如果函数需要返回一个空集合，返回 nil 切片而不是空切片——nil 切片不需要分配内存。但如果结果会被 JSON 序列化且期望 [] 而非 null，则使用空切片。

map：无序键值对

map 是 Go 中的哈希表实现，提供平均 O(1) 的查找、插入和删除：

// 创建
m1 := map[string]int{"a": 1, "b": 2}
m2 := make(map[string]int)      // 空 map
m3 := make(map[string]int, 100) // 预分配容量（性能优化）

// 增删改查
m1["c"] = 3                    // 插入/更新
delete(m1, "a")                // 删除
value := m1["b"]               // 查找（key 不存在返回零值）
value, ok := m1["b"]           // 查找 + 存在性检查

// 遍历
for key, value := range m1 {
    fmt.Printf("%s: %d\n", key, value)
}

map 的键类型要求：键必须是可比较的（comparable）。可以用作键的类型包括：所有基本类型、指针、数组、结构体（如果所有字段都可比较）、接口。不能用作键的类型：切片、map、函数。

// 合法的 map 键
map[int]string{}
map[[2]int]string{}         // 数组可以
map[struct{x,y int}]string{} // 可比较的结构体可以

// 非法的 map 键
map[[]int]string{}          // 编译错误：切片不可比较
map[map[int]int]string{}    // 编译错误：map 不可比较

nil map vs empty map

var m1 map[string]int       // nil map
m2 := map[string]int{}      // empty map
m3 := make(map[string]int)  // empty map

// 读操作对 nil map 安全
_ = m1["key"]              // 返回零值 0，不 panic
_, ok := m1["key"]         // ok = false
len(m1)                    // 0
for k, v := range m1 {}   // 0 次迭代

// 写操作对 nil map 不安全！
m1["key"] = 1              // panic: assignment to entry in nil map

规则：nil map 可读不可写。这是设计上的选择——读操作返回零值使得代码更简洁（不需要预检查），而写操作 panic 是因为没有底层存储可以写入。

常见的 map 使用模式

// 模式 1：集合（Set）
seen := make(map[string]struct{}) // 用空结构体节省内存
seen["alice"] = struct{}{}
if _, exists := seen["bob"]; !exists {
    fmt.Println("bob not seen")
}

// 模式 2：分组
groups := make(map[string][]string)
groups["fruits"] = append(groups["fruits"], "apple")
groups["fruits"] = append(groups["fruits"], "banana")

// 模式 3：计数
counts := make(map[string]int)
for _, word := range words {
    counts[word]++  // 零值为 0，直接 ++ 即可
}

// 模式 4：缓存/记忆化
cache := make(map[int]int)
func fib(n int) int {
    if v, ok := cache[n]; ok {
        return v
    }
    if n <= 1 {
        return n
    }
    cache[n] = fib(n-1) + fib(n-2)
    return cache[n]
}

Level 2 · 它是怎么运行的

切片的底层结构：SliceHeader

切片在内存中由三个字段组成，定义在 reflect.SliceHeader 中：

type SliceHeader struct {
    Data uintptr  // 指向底层数组的指针
    Len  int      // 当前元素数量
    Cap  int      // 底层数组的总容量
}

在 64 位系统上，SliceHeader 占 24 字节（8+8+8）。当你把切片传递给函数时，传递的是这 24 字节的拷贝——指针、长度和容量被复制，但底层数组不会。

func modify(s []int) {
    s[0] = 99  // 修改底层数组——调用方可见
    s = append(s, 100) // 可能触发新数组分配——调用方不可见
}

original := []int{1, 2, 3}
modify(original)
fmt.Println(original[0]) // 99 — 修改可见
fmt.Println(len(original)) // 3 — append 的效果不可见

这是一个极其重要的行为差异：

• 通过索引修改元素 → 修改的是共享的底层数组 → 对调用方可见
• append 导致扩容 → 创建新数组，修改函数内部的 SliceHeader → 对调用方不可见

切片截取与底层数组共享

切片截取操作（slicing）不会创建新的底层数组——新旧切片共享同一块内存：

original := []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
sub := original[3:7] // sub = [3, 4, 5, 6]

// sub 的底层结构
// Data: 指向 original 底层数组的第 3 个元素
// Len:  4 (7-3)
// Cap:  7 (10-3, 从起始位置到底层数组末尾)

sub[0] = 99
fmt.Println(original[3]) // 99 — 共享底层数组！

完整的三索引切片（three-index slice, Go 1.2+）可以限制容量：

sub := original[3:7:7] // [low:high:max]
// Len = high - low = 4
// Cap = max - low = 4（不是 7！）

// 现在 append 到 sub 一定会触发新分配，不会覆盖 original 的后续元素
sub = append(sub, 100)
fmt.Println(original[7]) // 7，没有被覆盖

三索引切片是防止切片追加覆盖的防御性编程技巧——后面在陷阱部分会详细讨论。

append 的扩容规则

当 append 发现当前容量不足时，会分配新的底层数组。扩容策略经历了重大变化：

Go 1.17 及之前的规则：

• 新容量 < 1024：翻倍（cap * 2）
• 新容量 >= 1024：增长 25%（cap * 1.25）

Go 1.18+ 的新规则（Robert Griesemer, "runtime: make slice growth formula more smooth", 2021）：

// runtime/slice.go 中的简化逻辑
func growslice(old []T, newLen int) []T {
    newcap := old.cap
    doublecap := newcap + newcap
    if newLen > doublecap {
        newcap = newLen
    } else {
        const threshold = 256
        if old.cap < threshold {
            newcap = doublecap
        } else {
            for newcap < newLen {
                newcap += (newcap + 3*threshold) / 4
            }
        }
    }
    // 最后还会进行内存对齐（向上取整到内存分配器的 size class）
}

关键变化：

1. 阈值从 1024 降到 256
2. 大切片的增长公式从 cap * 1.25 变为 (cap + 3*256) / 4，使得增长率更平滑——小容量时接近 2x，大容量时逐渐趋近 1.25x
3. 最终容量还会被内存分配器的 size class 向上对齐

为什么要改？ 旧规则在 1024 附近有一个断崖——从 2x 突然变成 1.25x。对于容量为 1023 和 1025 的切片，扩容行为截然不同。新规则消除了这个不连续性。

// 验证扩容行为
s := make([]int, 0)
prev := cap(s)
for i := 0; i < 10000; i++ {
    s = append(s, i)
    if cap(s) != prev {
        fmt.Printf("len=%d cap=%d (growth=%.2fx)\n", len(s), cap(s), float64(cap(s))/float64(prev))
        prev = cap(s)
    }
}
// Go 1.18+ 输出显示增长率从接近 2x 平滑过渡到接近 1.25x

append 的性能影响

理解扩容意味着理解性能：

// 不预分配：每次扩容需要拷贝现有数据 + GC 回收旧数组
func badPerf() []int {
    var s []int
    for i := 0; i < 100000; i++ {
        s = append(s, i) // 触发约 27 次扩容
    }
    return s
}

// 预分配：零扩容
func goodPerf() []int {
    s := make([]int, 0, 100000)
    for i := 0; i < 100000; i++ {
        s = append(s, i) // 永不扩容
    }
    return s
}

Benchmark 对比（Go 1.21, amd64）：

规则：如果你知道（或能估计）最终大小，始终使用 make([]T, 0, expectedSize) 预分配。

map 的底层实现

Go 的 map 使用开放寻址 + 链地址法混合的桶式哈希表（bucket hash table）实现。核心结构（runtime/map.go）：

// hmap 是 map 的运行时表示
type hmap struct {
    count     int    // 当前元素数量（len() 返回的值）
    flags     uint8  // 并发读写检测标志
    B         uint8  // 桶数量的 log2（桶数 = 2^B）
    noverflow uint16 // 溢出桶数量的近似值
    hash0     uint32 // 哈希种子（随机化）

    buckets    unsafe.Pointer // 桶数组指针（2^B 个桶）
    oldbuckets unsafe.Pointer // 扩容时的旧桶数组
    nevacuate  uintptr        // 扩容进度

    extra *mapextra // 溢出桶等额外信息
}

// bmap 是单个桶的结构
type bmap struct {
    tophash [8]uint8 // 每个键的哈希值高 8 位
    // 后面紧跟：8 个 key，8 个 value，1 个溢出桶指针
    // keys   [8]keyType
    // values [8]valueType
    // overflow *bmap
}

每个桶存储 8 个键值对。查找过程：

1. 计算 key 的哈希值 h
2. 用 h 的低 B 位确定桶号（h & (2^B - 1)）
3. 用 h 的高 8 位（tophash）在桶内快速筛选
4. 对 tophash 匹配的位置做完整的 key 比较
5. 如果当前桶没找到，沿溢出桶链表继续查找

为什么用 tophash？ 因为完整的 key 比较可能很昂贵（比如长字符串）。tophash 是一个 8 位的快速预筛选——桶内 8 个位置，先比较 1 字节，就能排除大部分不匹配的位置。

map 的扩容机制

map 在以下条件触发扩容：

1. 负载因子过高：count / 2^B > 6.5（平均每个桶超过 6.5 个元素）
2. 溢出桶过多：溢出桶数量超过常规桶数量

两种扩容方式：

• 翻倍扩容（条件 1 触发）：B 加 1，桶数翻倍
• 等量扩容（条件 2 触发）：桶数不变，但重新整理数据，消除稀疏的溢出桶

扩容是渐进式的（incremental）——不会一次性迁移所有数据，而是每次写操作时迁移 1-2 个旧桶。这避免了大 map 扩容时的长时间停顿。

// 扩容期间的状态
// oldbuckets != nil 表示正在扩容
// 读操作：先查 oldbuckets，再查 buckets
// 写操作：先迁移对应的旧桶，再执行写入

map 的哈希种子与遍历随机化

Go 的 map 有两个有意的随机化设计：

1. 哈希种子：每个 map 实例在创建时生成随机的 hash0，作为哈希函数的种子。这防止了哈希碰撞攻击（Hash DoS）——攻击者无法预测键会落在哪个桶中。

2. 遍历起始位置随机化：range 遍历 map 时，起始桶和桶内起始位置都是随机的。

m := map[string]int{"a": 1, "b": 2, "c": 3}
for k, v := range m {
    fmt.Printf("%s:%d ", k, v)
}
// 每次运行可能输出不同顺序
// 如：a:1 c:3 b:2 或 b:2 a:1 c:3

为什么要遍历随机化？ Go 团队故意这样做是为了防止开发者依赖 map 的遍历顺序（Russ Cox, Go 1 release notes, 2012）。在 Go 1 之前，map 遍历顺序恰好是确定的（因为实现细节），导致很多代码隐式依赖了这个顺序。一旦 map 实现变更，这些代码就会崩溃。通过引入随机化，任何依赖遍历顺序的代码在开发阶段就会暴露问题。

切片和 map 的 GC 交互

切片和 map 中存储指针时会影响 GC 性能。GC 需要扫描所有包含指针的对象来确定哪些内存可以回收。

// GC 不友好：每个元素都包含指针
type User struct {
    Name string  // string 内部有指针
    Age  int
}
users := make([]User, 1000000)
// GC 需要扫描 1000000 个 User，检查每个 Name 的指针

// GC 更友好：分离指针和非指针
type Users struct {
    Names []string
    Ages  []int
}
// GC 只需扫描 Names 切片的指针数组

对于 map：

// map[string]*BigStruct — GC 需要扫描所有值（都是指针）
// map[string]BigStruct  — 如果 BigStruct 不含指针，GC 不需要扫描值

// 优化技巧：如果 key 和 value 都不含指针，map 可以标记为无需 GC 扫描
// 这在 runtime 内部自动处理，但你需要注意类型设计

Level 3 · 规范怎么定义的

切片的规范定义

Go 语言规范对切片的定义：

A slice is a descriptor for a contiguous segment of an underlying array and provides access to a numbered sequence of elements from that array.

SliceType = "[" "]" ElementType .

关键规范细节：

切片表达式（Slice expressions）有两种形式：

// 简单形式：a[low : high]
// 完整形式：a[low : high : max]  (Go 1.2+)

规范规定的索引关系：0 <= low <= high <= max <= cap(a)

违反这些约束会导致运行时 panic（不是编译错误，因为索引值可能是运行时计算的）。

append 的规范行为：

If the capacity of s is not large enough to fit the additional values, append allocates a new, sufficiently large underlying array that fits both the existing slice elements and the additional values. Otherwise, append re-uses the underlying array.

规范没有指定具体的扩容策略——只保证"sufficiently large"。这意味着扩容策略是实现细节，不同版本可能不同（事实上 Go 1.18 确实改变了）。不要依赖具体的扩容行为。

copy 的规范行为：

The copy built-in function copies elements from a source slice into a destination slice. The source and destination may overlap. Copy returns the number of elements copied, which will be the minimum of len(src) and len(dst).

注意 "may overlap"——copy 正确处理源和目标重叠的情况（内部使用 memmove 而非 memcpy）。

map 的规范定义

A map is an unordered group of elements of one type, called the element type, indexed by a set of unique keys of another type, called the key type.

MapType = "map" "[" KeyType "]" ElementType . KeyType = Type .

关键规范细节：

键类型约束：

The comparison operators == and != must be fully defined for operands of the key type.

这排除了切片、map 和函数类型作为键。但规范还有一个微妙点——包含这些类型的结构体也不能作为键：

type Bad struct {
    data []int // 切片字段
}
// map[Bad]int{} // 编译错误：Bad 包含不可比较的字段

nil map 的规范行为：

A nil map is equivalent to an empty map except that no elements may be added.

规范明确指出 nil map 和空 map 的唯一区别是能否添加元素。所有读操作（查找、len、range）在 nil map 上都有良好定义的行为。

map 的并发访问：

规范没有直接说明并发安全性，但 Go 内存模型文档明确指出：

Maps are not safe for concurrent use: it's not defined what happens when you read and write to them simultaneously.

运行时通过 hmap.flags 检测并发读写。如果检测到，直接调用 throw()（不是 panic——程序立即终止，无法 recover）：

fatal error: concurrent map read and map write

数组和切片在规范中的区别

数组类型定义：

An array type specifies the number of elements in the array. Array types are always one-dimensional but may be composed to form multi-dimensional types.

ArrayType = "[" ArrayLength "]" ElementType .

切片类型定义：

A slice type denotes the set of all slices of arrays of its element type.

注意措辞差异：数组类型指定了"number of elements"（长度是类型的一部分），而切片类型描述的是"the set of all slices of arrays"（不涉及长度）。

Go 规范中的 for-range 语义

规范对 range 的定义影响了很多行为：

The iteration values are assigned to the respective iteration variables as in an assignment statement.

对于切片：

for i, v := range s {
    // v 是 s[i] 的拷贝，不是引用
}

"Assigned... as in an assignment statement" 意味着 v 是值拷贝。如果切片元素是大结构体，每次迭代都会拷贝整个结构体：

type BigStruct struct {
    data [1024]byte
}
items := make([]BigStruct, 1000)
for _, item := range items {
    // item 是 BigStruct 的拷贝（1024 字节）
    // 每次迭代拷贝一次
}

// 优化：使用索引访问避免拷贝
for i := range items {
    doSomething(&items[i])
}

对于 map：

The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next.

这是规范层面的保证——你绝对不能依赖 map 的遍历顺序。

内存对齐与切片/数组

Go 规范规定：

A struct or array type has size zero if it contains no fields (or elements, respectively) that have non-zero size. Two distinct zero-size variables may have the same address in memory.

这导致了一些有趣的行为：

// 零大小类型的切片
type Empty struct{}
s := make([]Empty, 1000000)
fmt.Println(unsafe.Sizeof(s[0])) // 0
// 整个 s 的底层数组大小为 0 字节！

但 SliceHeader 本身仍然占 24 字节。这就是为什么 map[T]struct{} 比 map[T]bool 更节省内存——不是因为 struct{} 不占内存（它确实不占），而是因为 map 的 value 部分大小为 0，每个桶少分配 8 字节（bool 是 1 字节，但对齐到 8 字节）。

make 和 new 的规范区别

// make 只用于 slice、map、channel
s := make([]int, 5, 10)   // 返回初始化的 slice（不是指针）
m := make(map[string]int)  // 返回初始化的 map
ch := make(chan int)       // 返回初始化的 channel

// new 用于任何类型，返回指针
p := new(int)             // *int，指向零值 int
sp := new([]int)          // *[]int，指向 nil slice

规范定义：

The built-in function make takes a type T, which must be a slice, map, or channel type, optionally followed by a type-specific list of expressions. It returns a value of type T (not *T).

The built-in function new takes a type T, allocates storage for a variable of that type at run time, and returns a value of type *T pointing to it.

关键区别：make 返回已初始化的值（可以直接使用），new 返回指向零值的指针。对于 map，new(map[string]int) 返回的是指向 nil map 的指针——写入会 panic。

Level 4 · 边界与陷阱

陷阱：切片追加覆盖

这是 Go 中最隐蔽的 bug 之一：

original := []int{1, 2, 3, 4, 5}
sub := original[1:3] // [2, 3], len=2, cap=4

// sub 的 cap 是 4，append 不会触发扩容
sub = append(sub, 99)
fmt.Println(original) // [1, 2, 3, 99, 5] — original[3] 被覆盖了！

根因：sub 和 original 共享底层数组。sub 的容量足够容纳新元素（cap=4, len=2），所以 append 直接写入底层数组的第 4 个位置——这恰好是 original[3]。

修复方案：

方案 1：使用三索引切片限制容量

sub := original[1:3:3] // cap = 3-1 = 2，与 len 相同
sub = append(sub, 99)  // cap 不够，分配新数组
fmt.Println(original)  // [1, 2, 3, 4, 5] — 安全

方案 2：使用 copy 创建独立切片

sub := make([]int, 2)
copy(sub, original[1:3])
sub = append(sub, 99) // 操作自己的底层数组

在生产代码中的真实影响：

// 一个 HTTP handler 中的真实 bug
func handleRequest(baseHeaders []string) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // BUG：所有请求共享 baseHeaders 的底层数组
        headers := append(baseHeaders, "X-Request-Id: "+requestID(r))
        // 如果 baseHeaders 的 cap > len，后续请求会覆盖前面请求的 header
        setHeaders(w, headers)
    }
}

// 修复
func handleRequest(baseHeaders []string) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        headers := make([]string, len(baseHeaders), len(baseHeaders)+1)
        copy(headers, baseHeaders)
        headers = append(headers, "X-Request-Id: "+requestID(r))
        setHeaders(w, headers)
    }
}

陷阱：map 并发写 panic

m := make(map[int]int)
var wg sync.WaitGroup

for i := 0; i < 10; i++ {
    wg.Add(1)
    go func(n int) {
        defer wg.Done()
        m[n] = n * n // 并发写入
    }(i)
}
wg.Wait()
// fatal error: concurrent map writes
// 这是 fatal error，不是 panic——无法 recover

为什么是 fatal error 而不是 panic？ Go 团队的设计决策是：并发 map 操作意味着存在数据竞争（data race），数据竞争会导致不确定行为。如果用 panic + recover 让程序继续运行，可能在已损坏的数据上执行后续操作，造成更大的问题。直接终止是最安全的选择。

解决方案：

方案 1：使用 sync.Mutex

type SafeMap struct {
    mu sync.RWMutex
    m  map[int]int
}

func (sm *SafeMap) Set(k, v int) {
    sm.mu.Lock()
    defer sm.mu.Unlock()
    sm.m[k] = v
}

func (sm *SafeMap) Get(k int) (int, bool) {
    sm.mu.RLock()
    defer sm.mu.RUnlock()
    v, ok := sm.m[k]
    return v, ok
}

方案 2：使用 sync.Map（特定场景性能更好）

var m sync.Map

m.Store("key", "value")
v, ok := m.Load("key")
m.Delete("key")
m.Range(func(k, v interface{}) bool {
    fmt.Println(k, v)
    return true // 返回 false 停止遍历
})

sync.Map 的适用场景（根据其文档）：

1. 键基本不变化（只读或写入频率远低于读取）——适合缓存
2. 多个 goroutine 读写不重叠的键集——适合分片处理

在其他场景下（频繁写入重叠键），sync.Mutex + 普通 map 通常更快。

陷阱：range 循环值拷贝

type Player struct {
    Name  string
    Score int
}

players := []Player{
    {"Alice", 100},
    {"Bob", 200},
}

// BUG：v 是拷贝，修改 v 不影响原切片
for _, v := range players {
    v.Score += 10 // 修改的是拷贝，无效
}
fmt.Println(players[0].Score) // 100，没变

// 修复方案 1：使用索引
for i := range players {
    players[i].Score += 10
}

// 修复方案 2：使用指针切片
pplayers := []*Player{
    {"Alice", 100},
    {"Bob", 200},
}
for _, v := range pplayers {
    v.Score += 10 // v 是指针的拷贝，但指向同一个 Player
}

陷阱：遍历时删除 map 元素

m := map[string]int{"a": 1, "b": 2, "c": 3, "d": 4}

// 规范允许在 range 中删除元素
for k, v := range m {
    if v%2 == 0 {
        delete(m, k) // 安全：删除当前或其他键
    }
}
// m 现在只有奇数值的键

// 但在 range 中添加元素的行为是不确定的
for k := range m {
    m[k+"_copy"] = m[k] // 新添加的键可能会也可能不会被遍历到
}

Go 规范明确指出：

If a map entry that has not yet been reached is removed during iteration, the corresponding iteration value will not be produced. If a map entry is created during iteration, that entry may be produced during the iteration or may be skipped.

陷阱：切片的内存泄漏

// 内存泄漏场景
func getFirstToken(data []byte) []byte {
    // data 可能是一个 1GB 的文件内容
    idx := bytes.IndexByte(data, ' ')
    return data[:idx] // 返回的小切片持有整个 1GB 底层数组的引用
}

// 修复：拷贝需要的数据
func getFirstToken(data []byte) []byte {
    idx := bytes.IndexByte(data, ' ')
    token := make([]byte, idx)
    copy(token, data[:idx])
    return token // 新的底层数组只有 idx 字节大小
}

这是切片引用语义的副作用：只要有任何切片引用底层数组的任何部分，整个底层数组都不会被 GC 回收。

同样的问题也出现在 append 的 "re-slicing" 中：

// 删除切片中间的元素
func removeIndex(s []int, i int) []int {
    return append(s[:i], s[i+1:]...)
    // 注意：s[len(s)-1] 位置的内存仍然持有旧值
    // 如果元素类型包含指针，旧值不会被 GC（内存泄漏）
}

// 修复：将尾部元素设为零值
func removeIndex(s []int, i int) []int {
    copy(s[i:], s[i+1:])
    s[len(s)-1] = 0 // 清除对旧对象的引用
    return s[:len(s)-1]
}

面试题：以下代码的输出是什么？

func main() {
    s := []int{1, 2, 3}
    
    for i, v := range s {
        if i == 0 {
            s = append(s, 4)
        }
        fmt.Print(v, " ")
    }
}

答案：1 2 3

解释：range 在开始时确定了遍历的长度（基于初始 len(s) = 3）。即使在循环中修改了 s（添加了元素 4），range 仍然只遍历原始的 3 个元素。但注意——如果你在循环中修改已有元素（通过索引），修改是可见的：

s := []int{1, 2, 3}
for i, v := range s {
    if i == 0 {
        s[2] = 99 // 修改已有元素
    }
    fmt.Print(v, " ")
}
// 输出：1 2 99
// 因为 range 使用的 s 和外部的 s 共享底层数组（在未扩容的情况下）

但如果第一次循环中的 append 触发了扩容（cap 不够），情况又不同了——range 使用的是旧的底层数组。这种行为的复杂性正是为什么不建议在 range 循环中修改被遍历的切片。

面试题：map 的值是不可寻址的

type Config struct {
    Debug bool
}

configs := map[string]Config{
    "app": {Debug: false},
}

// 编译错误：cannot assign to struct field configs["app"].Debug in map
configs["app"].Debug = true

// 为什么？因为 map 的值不可寻址（not addressable）
// map 可能在任何时候扩容重新分配，地址不稳定

修复方案：

// 方案 1：整体替换
c := configs["app"]
c.Debug = true
configs["app"] = c

// 方案 2：使用指针值
configs := map[string]*Config{
    "app": {Debug: false},
}
configs["app"].Debug = true // 可以，因为取的是指针的拷贝

性能优化：预分配的影响

// Benchmark 对比
func BenchmarkMapNoPrealloc(b *testing.B) {
    for i := 0; i < b.N; i++ {
        m := make(map[int]int)
        for j := 0; j < 10000; j++ {
            m[j] = j
        }
    }
}

func BenchmarkMapPrealloc(b *testing.B) {
    for i := 0; i < b.N; i++ {
        m := make(map[int]int, 10000)
        for j := 0; j < 10000; j++ {
            m[j] = j
        }
    }
}

典型结果：

预分配 map 避免了扩容过程中的多次重新哈希和数据迁移，性能提升约 50%。

真实案例：Kubernetes 中的切片陷阱

Kubernetes 源码中曾有一个经典 bug（kubernetes/kubernetes#81745）：

// 简化版本
func filterPods(pods []Pod, condition func(Pod) bool) []Pod {
    filtered := pods[:0] // 复用底层数组
    for _, p := range pods {
        if condition(p) {
            filtered = append(filtered, p)
        }
    }
    return filtered
}

问题：pods[:0] 创建了一个 len=0 但共享底层数组的切片。append 到 filtered 会覆盖 pods 中的数据。如果调用方之后仍然使用原始的 pods 切片，会看到被修改过的数据。

这种"原地过滤"模式只在调用方明确知道且接受底层数组会被修改时才安全。

工具：race detector 检测 map 并发

go run -race main.go
go test -race ./...

race detector 通过在编译时插入内存访问检测代码，能够在运行时精确报告数据竞争的位置：

==================
WARNING: DATA RACE
Write at 0x00c000090000 by goroutine 7:
  runtime.mapassign_fast64()
      /usr/local/go/src/runtime/map_fast64.go:92 +0x0
  main.main.func1()
      /tmp/main.go:15 +0x44

Previous write at 0x00c000090000 by goroutine 6:
  runtime.mapassign_fast64()
      /usr/local/go/src/runtime/map_fast64.go:92 +0x0
  main.main.func1()
      /tmp/main.go:15 +0x44
==================

建议：CI 中始终开启 -race 测试。race detector 的运行时开销约 5-10x，内存开销约 5-10x，适合测试但不适合生产。

本章深入解析了 Go 三大复合类型的设计与实现。切片的 SliceHeader + 底层数组共享机制解释了绝大多数"意外"行为；map 的桶式哈希 + 渐进扩容解释了其性能特征和并发限制。理解这些底层模型后，你写出的 Go 代码将不再产生"为什么这里数据莫名其妙变了"或"为什么突然 OOM 了"的困惑。

下一章我们将进入面向对象的世界——结构体、方法与接口——Go 用组合替代继承的哲学如何在类型系统中体现。