Go中传切片本质是值传递slice header（ptr/len/cap），修改元素影响底层数组，append扩容后新header不会更新调用方变量；需扩容时应返回新切片而非传*[]T。
Go 里传切片本质上传的是 slice header
切片不是引用类型，也不是值类型，而是一个包含 ptr、len、cap 三字段的结构体。函数参数传递时，这个结构体被复制——所以修改 slice[i] 会影响原底层数组，但 append 后若扩容，新 slice header 不会反向更新调用方的变量。
常见错误现象：append 后原变量长度没变、内容没更新；以为“传引用”就能自动扩展原切片。
- 如果只读或只改元素值（如
s[0] = 1），直接传[]T安全且高效 - 如果需要可能扩容并让调用方拿到新 header，必须返回新切片：
func extend(s []int) []int - 底层数组共享意味着并发写同一 slice 元素需加锁，哪怕切片变量本身是副本
什么时候必须用指针传切片？
极少需要。只有当你想在函数内重新赋值整个 slice 变量（比如 s = append(s, x) 之后还做了 s = s[1:] 或 s = make([]int, 0)），且希望调用方看到这个新 header 时，才考虑 *[]T。
但这会让代码难读、易错，通常应避免。更清晰的做法是显式返回：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
func addAndTrim(s []int, x int) []int {
s = append(s, x)
return s[1:]
}
// 调用方：s = addAndTrim(s, 5)
-
*[]T不解决底层数组共享问题，只是多一层间接寻址 - 性能上无优势，反而增加解引用开销和 nil 检查负担
- 标准库和主流 Go 项目几乎不用
*[]T做参数
对比 map、chan、*struct 等其他类型传参行为
切片和它们不同：map、chan、*struct 的底层数据结构本身带指针（如 hmap、hchan、实际内存地址），所以复制变量仍指向同一对象；而切片 header 是纯值，其 ptr 字段虽是指针，但 header 本身可被覆盖。
- 传
map[K]V：增删改 key 都影响原 map，无需返回或指针 - 传
chan T：发送/接收都作用于同一通道，同上 - 传
*MyStruct：改字段或调方法都影响原实例 - 传
[]T：改元素值 → 影响原数组；改 header（如s = append(s, ...)）→ 不影响调用方变量
容易被忽略的 cap 截断陷阱
当函数接收一个切片并做 append，即使没扩容，也可能因原 cap 不足导致后续操作意外截断。例如传入 s[:2]（底层数组长 5，但 cap=2），再 append 就必然扩容，header 完全脱离原切片上下文。
- 调试时可用
fmt.Printf("len=%d cap=%d ptr=%p", len(s), cap(s), &s[0])查看真实状态 - 若函数逻辑依赖足够大的
cap，应在文档注明，或主动用make([]T, len(s), cap(s))复制保障 - 不要假设“传进来的切片 cap 一定够”，尤其来自用户输入或外部 API
*，取决于你是否要重绑定 slice header 本身。绝大多数时候，不加，靠返回值更新，是最直白、最符合 Go 习惯的做法。 
