切片扩容后原底层数组指针是否还有效
无效。一旦发生扩容，append 会分配新底层数组，原切片指向的内存地址彻底失效，所有基于旧底层数组地址的指针（比如 &s[0]）不再指向当前数据。
常见错误现象：unsafe.Pointer 转换后读取崩溃、C 函数传入的指针突然读到垃圾值、并发中一个 goroutine 修改了扩容后的切片，另一个仍用旧地址读写导致数据错乱。
- 仅当容量足够时，
append不扩容，&s[0]地址不变 - 扩容触发条件是
len(s) == cap(s)，不是“看起来满了”——注意中间有copy或s = s[:n]操作可能隐藏真实容量 - 用
reflect.ValueOf(s).Pointer()可验证地址是否变化，但别在生产逻辑里依赖它
如何安全地把切片传给需要固定内存地址的 C 函数
必须确保调用期间不发生扩容，且生命周期可控。Go 的 slice 本身不保证内存稳定，得靠约束使用方式来兜底。
使用场景：调用 C.write、C.sqlite3_bind_blob、图像处理库的 raw pixel buffer 等。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 预先用
make([]byte, 0, N)分配足量容量，后续只用append填充，避免中途扩容 - 或改用
make([]byte, N)固定长度，再用s = s[:used]控制逻辑长度，这样&s[0]始终有效 - 传指针前加
runtime.KeepAlive(s)防止 Go 提前回收底层数组（尤其在函数尾部有 C 调用时） - 绝不把切片变量本身传进 C，只传
&s[0]；且 C 函数返回后立刻停止访问该地址
为什么 s = append(s, x) 后 &s[0] 有时变有时不变
取决于当前 cap(s) 是否够用。Go 的扩容策略（近似 2 倍增长）和底层内存分配器行为共同决定地址是否复用，但你不该依赖这个“有时不变”。
参数差异：append 是值传递，返回的是新切片头（包含新指针/长度/容量），原变量若未被赋值就会继续指向旧底层数组。
- 典型坑：
func f(s []int) { s = append(s, 1); fmt.Printf("%p", &s[0]) }—— 这里s是副本，函数内扩容不影响调用方，但打印的地址是新数组的 - 性能影响：频繁扩容触发多次 malloc/free，小切片反复重分配比预分配慢 3–5 倍（实测常见于日志缓冲、协议编码）
- 兼容性无问题，但跨 Go 版本的扩容阈值略有调整（如 1.21 对小 slice 更激进），别硬编码“扩容一定发生在 len==cap 时”
检查切片是否已扩容的可靠方法
不能靠比较 &s[0] 地址，因为即使没扩容，GC 移动内存（如启用 GODEBUG=madvdontneed=1）也可能导致地址变。真正可靠的判断依据只有容量变化和底层 header 对比。
- 最简方式：
oldCap := cap(s); s = append(s, x); if cap(s) != oldCap { /* 扩容了 */ } - 更彻底：用
reflect.SliceHeader对比Data字段，但需//go:uintptr注释且仅限 unsafe 场景 - 调试时可用
fmt.Printf("ptr=%p len=%d cap=%d", &s[0], len(s), cap(s))，但别在日志里高频打这个——&s[0]在空切片时 panic - 容易忽略的点：
s[:0]不改变底层数组地址，但cap(s)不变；而s = s[:0:0]会重置容量，可能导致下次append立即扩容
复杂点在于，你无法从外部感知某个切片变量背后是否被其他代码悄悄 append 过。只要涉及共享底层数组 + 可能扩容的操作，就必须按“随时会失效”来设计内存生命周期。
