go切片是值类型，赋值或传参时仅复制sliceheader（ptr、len、cap），不复制底层数组；修改元素影响原数组，但append等操作改变切片变量自身不影响调用方。
Go切片是值类型，但底层数据是共享的
切片变量本身是值类型——赋值或传参时会复制 sliceHeader（含 ptr、len、cap 三个字段），不是复制底层数组。所以修改切片元素会影响原底层数组，但修改切片变量自身（比如 s = append(s, x)）不会影响调用方的变量。
常见错误现象：
- 认为“传切片进函数能自动扩容原切片”，结果 append 后原变量没变；
- 在循环中反复 append 同一个切片并存入 map/slice，结果所有条目指向同一底层数组，最后全变成最后一次的值。
- 使用场景：需要共享数据但避免拷贝时（如解析大 JSON 后切分字段）；需隔离修改时（如并发处理不同子段）必须显式
copy或重建切片 - 参数差异：函数接收
[]int是传值（Header 复制），但*[]int才能真正改变调用方的切片头（极少用，通常说明设计有问题） - 性能影响：零拷贝访问底层数组，快；但意外共享易引发隐蔽 bug，调试成本高
切片 Header 的三个字段怎么影响行为
sliceHeader 是运行时内部结构，Go 不暴露其定义，但可通过 unsafe 观察。它实际就是三个机器字长的字段：ptr（指向底层数组首地址）、len（当前长度）、cap（容量上限）。三者共同决定切片的“视图范围”和是否能安全 append。
典型问题：
- cap 小于 len？不可能，编译器/运行时保证 len ；<br>
- <code>ptr 为 nil 但 len > 0？可能，比如 var s []int，此时 s == nil 且 len(s) == 0，但若手动构造非法 Header（不推荐），会导致 panic 或读写越界。
- 扩容逻辑：当
len + 1 > cap时，append会分配新底层数组，原ptr失效；旧数据被复制，新切片与原切片不再共享底层数组 - 兼容性注意：不同 Go 版本对小切片（
cap ）的扩容倍数略有差异（1.25x vs 2x），依赖具体容量做判断的代码可能跨版本行为不一致 - 示例：
s := make([]int, 2, 4)→ptr指向某块内存，len=2，cap=4；s = s[:3]只改len，ptr和cap不变；s = append(s, 1)仍可用原底层数组（因3 ）
为什么 nil 切片和空切片在 append 行为上一样
因为 nil 切片的 ptr 为 nil、len 和 cap 都为 0，而 make([]int, 0) 创建的空切片 ptr 非 nil、len=0、cap=0。但 append 对两者处理一致：首次追加时都分配新底层数组。
容易踩的坑：
- 用 == nil 判断切片是否为空 —— 错！len(s) == 0 才是正确方式；
- 在 JSON 解码时，"items": null 和 "items": [] 解到 []string 字段，前者得 nil，后者得空切片，但 len 都是 0，append 行为无差别。
- 性能差异：几乎可忽略；但
nil切片序列化为 JSON 是null，空切片是[]，API 兼容性上需留意 - 反射判断：
reflect.ValueOf(s).IsNil()能区分nil和空切片，但日常业务中极少需要
想彻底隔离切片数据？别只靠 make + copy
直接 make([]T, len(s)) 再 copy 是最常用做法，但要注意：如果原切片的元素是引用类型（如 []*int），copy 只复制指针，底层数值仍共享。真要深拷贝，得遍历并新建每个元素。
立即学习“go语言免费学习笔记（深入）”；
常见错误现象：
- 对 []map[string]int 做 copy 后修改某个 map，发现原切片里对应位置的 map 也被改了；
- 并发写入多个 goroutine 分到的子切片，以为用了 copy 就安全，结果子切片里的指针仍指向同一堆内存。
- 简单值类型（
int、string、struct{...}）：copy安全 - 含指针/切片/映射的结构体：需逐字段深拷贝，或用
encoding/gob/json序列化再反序列化（重但通用） - 性能权衡：深拷贝开销大，若只是临时读取或只读场景，用
unsafe.Slice（Go 1.17+）构造只读视图更轻量
事情说清了就结束。Header 结构虽简单，但 ptr、len、cap 三者组合出的行为边界，比表面看起来更微妙——尤其在并发、序列化、跨包传递时，稍不注意就会掉进共享与隔离的灰色地带。
