go切片底层存有data指针、len长度、cap容量三个字段；传参时拷贝这三者，修改元素影响底层数组，append扩容后原切片仍有效但指向旧数组。
Go 切片底层到底存了哪三个字段
Go 切片不是引用类型，也不是指针类型，它本身是个值——由 reflect.SliceHeader 对应的三字节结构体：一个指向底层数组的指针（Data）、当前长度（Len）、容量（Cap）。你每次传切片进函数，实际拷贝的就是这三个字段。所以修改切片元素会反映到底层数组，但追加（append）后若触发扩容，原切片的 Data 和 Len 就不再同步新切片。
用 unsafe.SliceHeader 强制转换时为什么常 panic
直接把数组指针转成 unsafe.SliceHeader 再转回切片，看似能绕过 make，但极易出错：
-
Data字段必须对齐：比如*int64指针不能赋给uintptr后直接塞进Data，否则在某些架构（如 ARM64）上触发总线错误 -
Len和Cap不能超数组真实边界，运行时不会校验，越界读写直接导致 undefined behavior - GC 不知道这个手工构造的切片持有哪块内存，若原数组被回收，
Data变成悬垂指针
示例中常见错法：sh := (*unsafe.SliceHeader)(unsafe.Pointer(&arr)) —— 这里 &arr 是数组地址，但 arr 若是局部变量，生命周期一结束就危险。
什么时候真需要操作 SliceHeader
绝大多数业务代码完全不需要碰它。真正绕不开的场景极少，集中在：
立即学习“go语言免费学习笔记（深入）”；
- 零拷贝网络包解析（如从
[]byte中快速切出 header/body，且确定生命周期可控） - 高性能序列化库内部（如
gogoproto序列化时复用缓冲区） - 和 C 互操作时接收 C 分配的内存块，需构造成 Go 切片
此时推荐用 unsafe.Slice（Go 1.17+）替代手写 SliceHeader，它自动处理对齐和边界检查（编译期），比裸指针安全得多。例如：unsafe.Slice((*int)(ptr), len)。
append 扩容后原切片还有效吗
有效，但和新切片无关。扩容本质是分配新数组、复制数据、更新新切片的 Data/Len/Cap；原切片三个字段全没变，仍指向旧数组。常见误判：
- 以为
s = append(s, x)后，所有基于旧s的变量都自动更新 → 错，它们仍用老地址 - 在循环中反复
append却没接返回值：append(s, x)被丢弃，下次还是用旧切片，可能静默覆盖或越界 - 用
cap预估内存占用，却忽略扩容倍数策略（小容量翻倍，大容量按 1.25 增长），导致预估偏差很大
记住：切片是值，append 返回新值，不修改输入。
真正难的不是理解三个字段，而是判断某段代码里哪些变量共享底层数组、谁在何时持有有效指针、GC 是否能感知——这些没法靠看 SliceHeader 字段推出来，得结合作用域、逃逸分析和运行时行为一起看。
