Go切片传参时底层数组不拷贝，但切片头（ptr、len、cap）被值拷贝；修改元素影响原切片，修改切片变量本身（如append、切片操作）不影响调用方，除非返回新切片并显式赋值。
Go切片传参时底层数组不会拷贝，但切片头结构体本身会复制
直接说结论：func f(s []int) 这种传参方式，s 是原切片的**值拷贝**——即复制了它的三个字段：ptr（指向底层数组的指针）、len、cap。底层数组不会被拷贝，所以修改 s[i] 会影响原切片；但修改 s 本身（比如 s = append(s, x)）通常不会影响调用方的原始变量。
常见错误现象：
- 认为“传切片就是传引用”，结果在函数里 append 后原切片没变，以为是 bug
- 在函数里对切片重新赋值（如 s = s[1:] 或 s = make([]int, 5)），调用方完全感知不到
-
append是否影响原切片，取决于是否触发扩容：没扩容时复用原底层数组，元素可见；扩容后指向新数组，原切片不可见新元素 - 所有切片操作（
s[i:j]、s[:n]等）只改变len/cap和ptr偏移，不拷贝数据 - 如果想让函数能“替换”整个切片（包括长度、容量、甚至底层数组），必须传
*[]T（指向切片的指针）
什么时候 append 修改能被调用方看到？
仅当底层数组未发生扩容，且修改的是已有索引位置的元素（不是靠 append 新增）。append 本身返回的是新切片，原变量不变。
示例：
func modify(s []int) {
s[0] = 999 // ✅ 调用方能看到
s = append(s, 42) // ❌ 这个 s 是副本，不影响外层
if len(s) > cap(s[:len(s)-1]) { // 扩容判断较复杂，实际应避免依赖
fmt.Println("扩容了")
}
}- 安全做法：若需通过
append改变原切片，函数应返回新切片，由调用方显式赋值：s = modify(s) - 检查扩容的可靠方式是对比
len和cap：若len(s)+1 > cap(s)，则下一次append必扩容 - 不要用
reflect.ValueOf(s).Pointer()判断是否同底层数组——它返回的是切片头中ptr字段值，扩容后自然不同，但这个值本身无业务意义
传 *[]T 的真实用途和代价
只有当你需要函数内部彻底替换整个切片变量（比如清空并重建、切换到另一块内存、或统一管理 cap 预留）时，才值得用 *[]T。
立即学习“go语言免费学习笔记（深入）”；
示例场景：初始化一个可能为空的切片，并在函数中按需分配
func initSlice(p *[]int, size int) {
*p = make([]int, size)
}
// 调用：
var s []int
initSlice(&s, 10) // s 现在是 len=10, cap=10 的切片- 传
*[]T会多一次指针解引用，性能影响微乎其微，但可读性下降 - 绝大多数情况，返回新切片更符合 Go 的惯用法（如
strings.Builder.String()、bytes.Buffer.Bytes()） - 滥用
*[]T容易掩盖设计问题：比如本该用结构体封装状态，却靠指针强行改外部变量
容易被忽略的边界：nil 切片和零值切片行为一致
nil 切片（var s []int）和 make([]int, 0) 在大多数操作中表现相同：都可 append、可遍历（0 次）、len/cap 都是 0。但它们的 ptr 字段不同：nil 的 ptr 是 nil，而 make 出来的指向真实分配的数组（哪怕长度为 0）。
- 对
nil切片append会自动分配底层数组，行为安全 - 用
==比较两个切片永远为false（切片不可比较），别试图用if s == nil判断是否为空——应该用len(s) == 0 - 序列化（如
json.Marshal）时，nil切片输出null，make([]int, 0)输出[]，这点在 API 交互中必须明确区分
传参时到底要不要加星号，不取决于“想不想改内容”，而取决于“想不想改这个切片变量本身的三个字段”。多数时候，你只想改内容，那就别加；加了反而让调用方困惑。
