go中slice截取s[i:j]不分配内存因其仅更新sliceheader三字段（data、len、cap）并栈上拷贝，但因cap保留底层数组剩余空间，子切片会“钉住”整个底层数组导致内存泄漏。
Go 中的 slice 变量本身不存数据，只存三个字段：指向底层数组的指针、当前长度 len、最大可用长度 cap。这三者合起来就是运行时的 SliceHeader，它决定了你“看得到什么”和“还能往里写多少”。
为什么 s[i:j] 不分配内存，却可能引发内存泄漏
截取操作只是重新计算 Data 地址、更新 len 和 cap，整个 SliceHeader 在栈上拷贝，零堆分配。但问题在于：cap 会保留从新起始位置到底层数组末尾的全部空间。
- 比如大数组
big := make([]byte, 10（10MB），取 <code>small := big[100:101]，small的cap仍是约 10MB —— GC 无法回收big底层数组，因为small仍“持有”其大部分容量 - 这种现象在返回 HTTP 响应体片段、日志子串、配置项切片时特别隐蔽
- 修复方式不是避免截取，而是按需切断引用：用
append([]byte{}, small...)或copy(dst, small)构造独立底层数组
len 和 cap 的数值差异直接影响 append 行为
len 控制你能读/写的元素个数；cap 决定 append 是否就地写入还是触发扩容。两者差值就是“还能追加多少而不 realloc”。
-
s := make([]int, 5, 8)→len=5,cap=8，还能append3 个元素不扩容 -
s := make([]int, 0, 100)→len=0,cap=100，首次append就写入索引 0，不触发任何分配 - 错误写法：
var s []int后循环append→ 每次扩容都复制旧数据，cap从 0→1→2→4→8…，O(n²) 开销
通过 reflect.SliceHeader 查看或篡改 header 是危险操作
虽然可以用 (*reflect.SliceHeader)(unsafe.Pointer(&s)) 获取 header，但直接修改 Data 或 Cap 属于 unsafe 行为，绕过 Go 的内存安全边界。
- 常见误用：想“跳过前 N 字节”就手动改
Data += N * unsafe.Sizeof(int(0))—— 若原切片是栈变量或小数组，Data指向非法地址，运行时 panic - 正确替代：用标准截取
s = s[N:]，编译器保证地址合法且cap自动调整 - 仅在极少数场景（如零拷贝网络包解析）需手动构造 header，必须确保
Data指向已分配且生命周期可控的内存块
真正容易被忽略的不是 header 有哪三个字段，而是 cap 的语义：它不是“预留空间”，而是“从当前 Data 起，底层数组还剩多少可用字节”。这个隐含约束，会在跨 goroutine 传递切片、复用缓冲区、长期缓存子串时突然咬你一口。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
