go中slice传参复制切片头而非底层数组，故修改元素（如sl[i]=x）影响原切片，但重赋值（如sl=append(sl,x)）不影响；需显式拷贝（copy或append(nil,s)）隔离数据。
slice 作为函数参数时，**不会复制底层数组，但会复制切片头（header）**——这意味着修改元素会影响原切片，但重赋值（如 sl = append(sl, x)）通常不会。
这不是“传引用”或“传指针”的简单归类，而是 Go 特有的“传切片头值”机制。理解这一点，才能避开绝大多数坑。
为什么修改 sl[i] 会影响原切片？
因为 slice 头里包含一个指向底层数组的 ptr 字段。函数内通过该指针读写内存，和调用方看到的是同一块数组区域。
常见错误现象：
- 函数里改了
sl[0] = 99，外面发现原切片变了 - 误以为“传的是副本”，结果并发写入引发数据竞争
实操建议：
- 只要没触发扩容、没重新赋值
sl变量本身，所有基于索引的写操作都作用于原底层数组 - 调试时可用
fmt.Printf("%p", &sl[0])验证是否指向同一地址 - 若需隔离，必须显式拷贝：用
copy(dst, src)或append([]T(nil), src...)
append 后原切片为何有时不变？
append 是否影响原切片，取决于底层数组是否有足够 cap。
使用场景：
- 容量够：
append直接在原数组末尾写，sl长度变，但调用方看到的仍是旧长度（因函数内变量是副本） - 容量不够：分配新数组，
sl指针更新 —— 但这个新指针只存在函数栈里，不影响外部
关键点：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
append返回新切片，必须接收返回值：sl = append(sl, x)，否则无效 - 函数内
append不会改变调用方的sl变量（它只是个头副本），哪怕底层数组被复用 - 想让外部也“增长”，得返回新切片，或传入
*[]T（不推荐，破坏简洁性）
如何安全地传参避免意外共享？
当函数逻辑需要独立操作数据（比如排序、过滤、加解密），不能让副作用泄漏到上游。
实操建议：
- 明确意图：若只需读，加注释
// readonly；若需写且隔离，必须深拷贝 - 最简拷贝方式：
dst := make([]T, len(src)); copy(dst, src) - 一行式拷贝（适用于小切片）：
clone := append([]T(nil), src...)—— 利用nil切片触发新分配 - 避免用
make([]T, 0, cap(src))然后copy，容易误用成共享底层数组
性能提示：拷贝成本 ≈ O(n)，对大 slice 要评估；若只是临时读，不拷贝更高效。
什么时候必须关心 cap 而不只是 len？
截取、传递、拼接时，cap 决定后续操作是否隐式共享内存。
典型问题：
-
s := arr[2:4]→cap(s) == len(arr)-2，不是 2；后续append可能意外改写arr[4]之后的元素 - 函数接收
[]int，但调用方传的是bigSlice[100:101]，此时cap很大，append容易越界覆盖
实操建议：
- 用
make([]T, len)创建新切片，而非从大 slice 截取后直接传入敏感函数 - 调试时多打
fmt.Println(len(s), cap(s))，尤其在截取后、append前 - 对外暴露 API 时，若参数可能被长期持有，考虑用
append([]T{}, s...)强制断开底层数组联系
slice 看起来像值类型，行为却像轻量级引用。每次传参前，得下意识问一句：这里改元素，是否允许影响上游？golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
