append 后原切片不变，因 go 值传递切片结构体副本，append 返回新切片（可能指向新底层数组），必须显式赋值如 s = append(s, 1)；子切片共享底层数组易致意外修改，需用 copy 或 slices.clone 隔离。
append 不会自动更新原变量，切片共享底层数组是常态，不是 bug —— 是设计，但容易误用。
为什么 append 后原切片没变？
因为 append 返回的是新切片（可能指向新底层数组），而 Go 是值传递：传入函数的是 []T 结构体的副本，不是引用。即使两个切片的 array 字段指向同一块内存，一旦扩容，append 返回的新结构体里的指针就变了，原变量还指着旧结构体。
- 不赋值 = 白 append：
append(s, 1)不影响s，必须写成s = append(s, 1) - 扩容与否取决于当前
cap：容量够就原地追加（改底层数组）；不够就分配新数组、拷贝、返回新切片 - 用
fmt.Printf("%p", s)打印的是底层数组地址，不是切片变量本身的地址 —— 别被这个“相同地址”骗了
怎么避免多个切片意外修改同一底层数组？
当从一个切片派生出 s1 := s[2:5]、s2 := s[3:6] 这类子切片时，它们共用底层数组。改 s2[0] 可能悄悄改掉 s1[1] —— 调试时极难察觉。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 需要隔离数据时，显式深拷贝：
newS := make([]int, len(oldS)); copy(newS, oldS) - 用
slices.Clone（Go 1.21+）更简洁：newS := slices.Clone(oldS) - 初始化时留足
cap，减少后续append触发扩容的概率，降低指针意外切换风险 - 对敏感数据（如配置、凭证、中间计算结果），默认按需克隆，别赌“这次不会扩容”
函数里想通过 append 修改调用方的切片，该怎么传参？
不能靠传切片本身 —— 即使扩容没发生，append 返回值也得赋给原变量，而函数内赋值不影响外部变量。唯一可靠方式是传指针。
- 函数签名改成
func extend(s *[]int, v ...int)，内部用*s = append(*s, v...) - 或者更常见：直接返回新切片，由调用方决定是否赋值 —— 符合 Go 的惯用法，也更清晰
- 不要试图用
unsafe或反射绕过，代价远高于收益 - 注意：如果函数只读或只改元素（如
s[0] = 1），传切片就够了 —— 指针字段共享，改的是同一块内存
最常被忽略的一点：切片的 len 和 cap 是独立控制的。你看到 len=3, cap=10，不代表这 10 个位置都“可用”——cap 只表示底层数组从切片起始位置往后还有多长，它不保证安全，也不阻止越界写（运行时 panic）。共享、扩容、赋值，三者叠加，才是 slice 陷阱真正的温床。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
