切片（slice）是Go语言中使用频率最高的数据结构之一，但它的行为常常让初学者摸不着头脑：把切片传进函数，函数里改了下标元素，外面的切片也跟着变了；可是在函数里做append，外面的长度却纹丝不动。要解释这些现象，光靠背结论是不够的，必须回到切片的底层结构去看。本文将从runtime源码层面剖析切片的真实构成，讲清楚它为什么表现出引用类型的特征，以及哪些操作会触发数据共享、哪些操作会产生分离。
一、切片的底层结构：一个三字段的结构体
打开Go的runtime源码，可以在runtime/slice.go中找到切片的定义：
type slice struct {
array unsafe.Pointer // 指向底层数组的指针
len int // 长度
cap int // 容量
}这个结构非常关键。所谓切片，其实就是一个包含了三个字段的小结构体：第一个字段是指针，指向真正存放数据的底层数组；第二个字段len表示当前切片可访问的元素个数；第三个字段cap表示底层数组从指针位置开始到末尾还能容纳多少元素。我们在写len(s)和cap(s)时，实际读取的就是这两个字段。
理解了这个结构，就能明白为什么说切片“类似于引用类型”。严格来说，Go语言规范中并没有“引用类型”这个正式分类，切片是值类型，只不过它的值中包含了一个指针。当你把切片赋值给另一个变量，或者作为参数传给函数时，Go复制的是这个结构体本身——三个字段被完整拷贝了一份，但指针指向的底层数组并没有被复制。两个切片结构体指向同一块内存，这就是引用语义的来源。
可以打个比方：切片就像一张写着地址的纸条。把纸条抄一份给别人，别人手里的纸条内容一样，指向的也是同一栋房子。你通过纸条找到房子并重新刷了墙，别人再看这栋房子自然也是新墙；但如果你把纸条上的地址改了，改的只是你手里那张纸条，别人手里的纸条不受影响。
二、传参修改与append的行为差异从何而来
先看第一个经典场景：通过下标修改元素。
func modify(s []int) {
s[0] = 100
}
func main() {
s := []int{1, 2, 3}
modify(s)
fmt.Println(s) // 输出 [100 2 3]
}因为函数内的s和外面的s虽然结构体是两份，但array指针指向同一块底层数组，通过下标写入直接落在了共享的数组上，所以外部的修改是可见的。这是切片表现出引用行为最直接的证据。
再看第二个场景：在函数内append。
func appendItem(s []int) {
s = append(s, 99)
}
func main() {
s := make([]int, 0, 3)
s = append(s, 1, 2, 3)
appendItem(s)
fmt.Println(s, len(s)) // 输出 [1 2 3] 3
}结果外部切片毫无变化，原因要分两种情况讨论。第一种情况：如果cap还有剩余，append会把99写进底层数组的下一个空位，但这次写入只是数据层面的，函数内s的len字段从3变成4，而外部s的len仍然是3，所以外部看不到新元素，尽管底层数组的第4个位置已经被悄悄改写了——这是一个隐蔽的坑。第二种情况：如果cap不够了，append会分配一块更大的新数组，把旧数据复制过去再追加，此时函数内的s指向了全新内存，与外部彻底脱钩。
这就是为什么很多有经验的Go开发者会建议：如果函数内部会修改切片的长度，要么传入*[]T指针，要么把append后的结果作为返回值交还给调用方，比如标准库中append函数本身就是返回新切片的设计，遵循了这个惯例。
三、切片截取与扩容中的数据共享陷阱
切片表达式同样会造成数据共享。执行s2 := s1[1:3]时，s2并不会复制数据，而是新建一个结构体，array指针指向s1底层数组的第1个元素，len为2，cap为从该位置到数组末尾的长度。也就是说，s1和s2在重叠区间内操作的是同一份内存。
func main() {
s1 := []int{1, 2, 3, 4, 5}
s2 := s1[1:3]
s2[0] = 200
fmt.Println(s1) // 输出 [1 200 3 4 5]
// append覆盖陷阱：s2的cap到数组末尾还有空间
s2 = append(s2, 999)
fmt.Println(s1) // 输出 [1 200 3 999 5]，s1[3]被覆盖
}上面代码中的append没有触发扩容，因为s2的cap足够，于是999直接写进了s1也在使用的那块数组区域，把s1原本的4覆盖成了999。这种bug在线上往往非常难查。解决办法是在截取时显式限制容量：s2 := s1[1:3:3]，三下标写法把cap也限制为3减去1等于2，这样后续对s2的append必然扩容，两份数据从此互不干扰。
另外值得一提的是扩容策略本身。当cap不足以容纳新元素时，Go会按一定规则计算新的容量（早期版本是小于1024时翻倍，之后按1.25倍增长，新版本采用了更平滑的策略），分配新数组并搬运数据。扩容之后的新切片与旧切片在array指针上彻底分道扬镳，对旧切片的后续写入不会影响新切片。理解这一点在处理大切片复用时很重要，例如利用s[:0]复用底层数组做对象池时，一定要确认没有其他切片还在引用同一块内存，否则容易出现数据竞争，需要配合互斥锁或sync.Pool来保证安全。
四、判断与验证：用代码看穿切片行为
除了直接读源码，还可以通过一些小实验验证上面的结论。比如用%p打印切片的地址，用unsafe包或反射观察结构体字段，都能直观看到指针共享与分离的时刻。
func main() {
s := make([]int, 3, 10)
s2 := s[:2]
fmt.Printf("s: %p\ns2: %p\n", s, s2) // 地址相同，共享底层数组
s3 := append(s, 1, 2, 3, 4, 5, 6, 7, 8) // 超出cap，触发扩容
fmt.Printf("s3: %p\n", s3) // 地址改变，指向新数组
}归纳一下切片的行为准则：只读和按下标写操作跟随指针走，凡是涉及结构体三个字段变化的操作（重新append赋值、三下标截取、copy到新切片），都会产生新的引用关系。写代码时牢记“结构体按值复制、底层数组共享”这一条主线，就能准确预判任何切片操作的结果，不再被引用语义的表象迷惑。