因为切片是底层数组的“三元视图”（指针+长度+容量），修改元素或未扩容的append会直接操作共享底层数组，导致原数据变化；扩容后则指向新数组，互不影响。
修改切片元素为什么原数据跟着变？
因为切片不是数据本身，只是个“三元视图”：一个指针 + 长度 + 容量。当你写 s[0] = 99，Go 实际是用这个指针算出内存地址，直接往底层数组里写——而所有共享该数组的切片（比如 a := s、b := s[1:]）看到的是同一块内存。
append 有时改得了、有时改不了？看扩容没
关键在容量是否够用：append 不会总新建数组，只在 len + 新增数量 > cap 时才扩容。扩容后新切片指向新底层数组，原切片完全不受影响；没扩容时，append 就是在原数组末尾填数，所有共享者都能看到新增元素。
- 安全判断方式：
fmt.Printf("cap: %d, len: %d", cap(s), len(s)) - 验证是否扩容：打印
&s[0]地址，append前后对比是否变化 - 别依赖
*[]T指针传参来“保证修改生效”——扩容后它只改了局部变量
想彻底隔离？必须深拷贝底层数组
赋值、传参、s[:] 都只是复制头信息，不解决共享问题。要让函数内操作不影响原始切片，唯一可靠方式是创建独立底层数组：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐：
out := append([]byte(nil), src)—— 零分配开销，Go 官方惯用法 - 等效但稍啰嗦：
out := make([]byte, len(src)); copy(out, src) - 绝对避免：
out := src、out := src[:]、out := src[0:len(src)]
结构体字段含切片时最容易翻车
比如 type Rule { Right []string }，当把 rule.Right 赋给局部变量再 append，若未扩容，就可能意外改到其他 Rule 的 Right 数据——尤其在遍历 []*Rule 时，多个 rule 指针共享同一底层数组的情况很隐蔽。
立即学习“go语言免费学习笔记（深入）”；
- 修复原则：凡是要修改结构体中切片字段的内容，先做深拷贝再操作
- 别省那点内存：宁可多一次
append([]T(nil), field)，也别赌“这次不会扩容” - 并发场景下更要警惕：共享底层数组 + 原地修改 = 数据竞争高发区
最常被忽略的一点：切片的“值类型”标签只管传递方式，不管内存归属。真正决定能否修改原数据的，从来不是“它是不是值类型”，而是“你动的是指针指向的哪块内存”。
