sliceHeader 是 Go 运行时内部描述切片的非公开结构体，含 data、len、cap 字段；直接操作会绕过内存安全机制，导致 GC 异常、越界或未定义行为，应使用 unsafe.Slice 等安全替代方案。
sliceHeader 是什么，为什么不能直接用
sliceHeader 是 Go 运行时内部用来描述切片的结构体，包含 data（底层数组指针）、len 和 cap 三个字段。它不是公开 API，也不在 reflect 包里稳定暴露——Go 1.17 后甚至把 reflect.SliceHeader 标记为“不安全且不推荐使用”。直接读写 sliceHeader 会绕过 Go 的内存安全机制，触发 go vet 报警，且在 GC 优化或编译器升级后行为不可靠。
常见错误现象：unsafe.SliceHeader 转换后取 data 指针，结果指向已回收内存；或用 reflect.SliceHeader 强制覆盖 len 导致越界读不报错但数据错乱。
- 真正需要底层控制时，应优先用
unsafe.Slice（Go 1.17+）或reflect.SliceHeader+unsafe.Pointer配合unsafe.String/unsafe.Slice等安全封装 - 永远不要对
sliceHeader做赋值、结构体拷贝或跨 goroutine 共享 - 调试时可用
fmt.Printf("%#v", reflect.ValueOf(s).UnsafeAddr())查看底层地址，但别依赖具体布局
如何安全地获取切片底层数组指针
想拿到 []byte 或 []int 的起始地址（比如传给 C 函数），正确做法是用 unsafe.Slice + unsafe.Pointer，而不是手撕 sliceHeader。
使用场景：对接 CGO、零拷贝序列化、高性能 buffer 复用。
立即学习“go语言免费学习笔记（深入）”；
- Go 1.17+ 推荐：
ptr := unsafe.Slice(unsafe.StringData(string(s)), len(s))（对[]byte）或unsafe.Slice(&s[0], len(s))（要求切片非空） - Go 1.16 及更早：必须先判断
len(s) > 0，再用&s[0]取地址，否则 panic；空切片要特殊处理（如用unsafe.Pointer(nil)） - 注意
unsafe.Slice不检查边界，传入负长度或超 cap 会导致未定义行为
为什么修改 sliceHeader.len 会出问题
有人试图通过反射修改切片长度来“扩展”容量，比如把 len 改成比 cap 还大。这不会报错，但后续写操作可能覆盖相邻内存，或被 GC 当作无效引用清理掉。
典型错误现象：修改后读数据正常，但过几轮 GC 就出现随机乱码；或在 go build -gcflags="-d=ssa/check_bce=0" 下崩溃。
-
len和cap是运行时校验边界的关键，篡改后append可能不扩容直接写越界 - 即使你确认底层数组还有空间，Go 也不保证该内存块在后续调度中仍归你独占
- 真要复用底层数组，请用
s = s[:cap(s)]再append，让运行时自己管理
CGO 场景下传递切片的正确姿势
在调 C 函数时，常需把 []byte 转成 *C.char 或 *C.int。错误做法是取 sliceHeader.data 再转指针；正确路径是明确生命周期并用 C.CBytes 或 unsafe.Slice。
性能影响：用 C.CBytes 会拷贝，适合小数据；用 unsafe.Slice 零拷贝但要求 Go 侧不释放内存，需手动 C.free 或确保 C 侧使用完前 Go 不 GC。
- 小量数据（C.CBytes(s)，返回
*C.uchar，记得C.free - 大量数据且 C 侧只读：用
(*C.char)(unsafe.Pointer(&s[0]))，但必须保证s在 C 调用期间不被 GC（加runtime.KeepAlive(s)） - 绝对不要对空切片做
&s[0]，改用nil指针并单独传长度
最易被忽略的是：C 函数如果保存了传入的指针并在回调中使用，必须用 runtime.Pinner（Go 1.23+）或 C.malloc 分配内存，否则 Go 的栈收缩或 GC 移动会让指针失效。
