修改切片影响另一个是因为它们共享底层数组；切片是含ptr、len、cap的结构体，slicea[1:]与slicea共用数组，故sliceb[0]=99会改slicea；append仅在cap不足时扩容并断开共享。
为什么修改一个切片会影响另一个？
因为多个 []int 可能共用同一段底层数组，它们的 data 字段指向同一个内存地址。这不是 bug，是设计使然——切片本质是“描述数组片段的结构体”，包含 ptr、len、cap 三个字段。
常见错误现象：sliceA := []int{1,2,3}; sliceB := sliceA[1:]; sliceB[0] = 99; fmt.Println(sliceA) 输出 [1 99 3]，而非预期的不变。
- 只要没触发扩容（即操作未超出当前
cap），新切片和原切片就共享底层数组 -
append是唯一可能“断开”共享的操作，但仅当容量不足、需要分配新数组时才发生 - 用
make([]T, len, cap)显式指定cap，比直接切分更可控
append 后底层数组一定变了吗？
不一定。是否扩容取决于当前长度与容量的关系，以及 append 的元素个数。
使用场景：批量追加数据时，若频繁触发扩容，会带来内存拷贝开销；但若预估容量并提前 make，就能避免。
立即学习“go语言免费学习笔记（深入）”；
- 当
len(s) ，<code>append(s, x)直接写入原数组，不改变ptr - 当
len(s) == cap(s)，append会分配新数组（通常是翻倍扩容），旧数据被拷贝过去 - 扩容策略不是标准保证，不同 Go 版本或实现略有差异，不能依赖具体倍数
- 可借助
unsafe.Sizeof或reflect.Value.Pointer()检查ptr是否变化，但生产环境慎用
如何安全地复制切片避免共享？
用 copy 函数或 append 空切片是最常用且明确的方式，它们都强制创建新底层数组。
性能影响：小切片复制开销可忽略；大切片需注意内存分配和 GC 压力。
-
newSlice := make([]int, len(old)); copy(newSlice, old)—— 最清晰，语义明确 -
newSlice := append([]int(nil), old...)—— 利用nil切片作为目标，简洁但稍隐晦 - 别用
newSlice := old[:len(old):len(old)]，这只是设置新cap，仍共享底层数组 - 如果后续只读，共享反而省内存；写前不确定是否修改，就老老实实
copy
调试时怎么快速判断两个切片是否共享底层数组？
打印它们的底层指针最直接。Go 不提供公开 API 获取 data 字段，但可通过 reflect 或 unsafe 观察。
容易踩的坑：在非调试场景滥用 unsafe，或误把 len/cap 相同当成共享依据。
-
reflect.ValueOf(s).Pointer()可返回底层数组起始地址（对非空切片有效） - 空切片（
len==0）可能返回 0，此时需结合cap和实际行为判断 - 对比两个指针值相等，只能说明“当前共享”，不代表未来一定共享（比如其中一个刚
append扩容了） - 线上环境别用
unsafe，调试脚本里用reflect就够了
底层数组共享是 Slice 的核心机制，不是缺陷，但它的“隐形性”会让新手误以为是 bug。真正难的不是记住规则，而是在写业务逻辑时，下意识问一句：这个切片接下来会不会被改？改的人是不是只有我？
