go切片传参时传递的是包含ptr、len、cap的结构体副本，ptr值被复制但指向同一底层数组；修改元素生效，append等操作需返回新切片才能影响调用方。
Go 切片传参时底层到底传了什么
切片不是引用类型，也不是值类型，它是个结构体：包含 ptr（指向底层数组的指针）、len 和 cap。函数传参时，这个三元结构体是按值拷贝的——也就是说，ptr 的值（地址）被复制了一份，但两个切片仍指向同一块底层数组。
这就解释了为什么修改元素会生效，而追加（append）后原切片可能“没变”：因为 append 可能分配新数组，返回的新切片结构体不会自动回传给调用方。
修改元素 vs 修改切片头：两种行为完全不同
对切片内已有索引位置赋值（如 s[0] = 10），操作的是共享的底层数组，调用方可见；但任何改变 len 或 cap、或导致底层数组迁移的操作（比如 append、s = s[1:]、s = append(s, x)），只影响函数内的切片头副本。
- ✅ 安全且可见：遍历修改、下标赋值、
copy到另一切片 - ❌ 不可见（除非显式返回）：
append、重切（s = s[2:4]）、扩容操作 - ⚠️ 隐患点：如果函数内做了
append但没返回，调用方看到的仍是旧长度和旧内容
想让 append 生效？必须显式返回新切片
Go 没有“引用传递”，所以靠参数本身无法让 append 改变调用方变量。唯一可靠方式是函数返回新切片，并由调用方重新赋值。
立即学习“go语言免费学习笔记（深入）”；
示例：
func addOne(s []int, x int) []int {
return append(s, x)
}
// 调用方必须接住返回值
s := []int{1, 2}
s = addOne(s, 3) // ✅ 正确
// s = addOne(s, 3) 这一步不能省
常见错误：写了个 push 函数却没返回，还指望 s 自动变长——它不会。
用指针传切片？通常没必要，还更难懂
有人试图传 *[]int 来“绕过”这个问题，但这是过度设计。除了极少数需要动态替换整个切片头（比如把 nil 切片初始化成非空）的场景，绝大多数情况返回新切片更清晰、更符合 Go 习惯。
用 *[]int 带来的问题：
- 调用方必须取地址：
foo(&s)，容易漏写& - 函数内部要解引用才能操作：
*s = append(*s, x)，多一层间接 - 和标准库、周边生态（如
json.Unmarshal）不一致，后者也靠返回值或额外参数（interface{}）处理
真正要注意的，其实是底层数组是否被意外共享——比如从一个大数组切出小切片又长期持有，导致 GC 无法回收原数组。那才是比“传参是不是引用”更隐蔽、更常踩的坑。
