Go切片是含指针的结构体值，按值传递但共享底层数组；append是否修改原slice取决于是否扩容：容量足够则共享修改，不足则新建数组、原slice不变。
Go语言切片（slice）既不是纯粹的值类型，也不是引用类型，而是一个“描述动态数组的结构体值”——它本身按值传递，但底层数据通过指针共享。
为什么 append 有时修改原 slice，有时不修改？
根本原因在于 append 是否触发底层数组扩容：
- 若容量足够，
append直接在原底层数组追加，所有指向该底层数组的 slice 都能看到新元素（比如通过len读到） - 若容量不足，
append分配新底层数组、拷贝旧数据、返回新 slice —— 此时原 slice 的ptr、len、cap全部不变，不受影响 - 关键点：函数参数传的是 slice 结构体副本，但其内部
ptr字段仍是原指针；扩容后新 slice 的ptr指向新地址，与原 slice 再无关联
slice 结构体字段怎么看？
用 unsafe.Sizeof 或源码可知，slice 在运行时本质是三字段结构体：
type slice struct {
array unsafe.Pointer // 指向底层数组首地址
len int
cap int
}
这意味着：
立即学习“go语言免费学习笔记（深入）”；
- 赋值或传参时，这三个字段被完整复制（值语义）
- 但
array是指针，所以多个 slice 可能array字段相同 → 共享同一块内存 -
len和cap独立，修改一个 slice 的len（如切片操作s[1:3]）绝不会影响另一个
如何判断两个 slice 是否共享底层数组？
没有标准库函数直接判断，但可通过 reflect 或 unsafe 比较底层指针：
func sameBase(s1, s2 []int) bool {
h1 := (*reflect.SliceHeader)(unsafe.Pointer(&s1))
h2 := (*reflect.SliceHeader)(unsafe.Pointer(&s2))
return h1.Data == h2.Data
}
注意风险：
- 依赖
reflect.SliceHeader属于非安全操作，仅用于调试或极端场景 - 编译器可能优化掉某些 slice 的底层数组（如小切片逃逸分析后栈分配），此时比较结果不稳定
- 更安全的做法是：明确控制数据所有权，避免依赖“是否共享”的隐式假设
真正容易被忽略的，是函数内对入参 slice 做 append 后未返回新值，就以为调用方 slice 已更新 —— 实际上除非扩容未发生且你操作的是同一底层数组的可见范围，否则根本没变。
