go中s[i:j]截取不分配堆内存，因切片是值类型，编译器直接在栈上构造新sliceheader，仅更新data、len、cap字段；其cap基于原cap而非底层数组长度，且新旧切片共享底层数组。
Go 中 s[i:j] 这类截取操作本身不分配内存，也不触发 GC；它只是计算新 Data 地址、更新 len 和 cap，然后在栈上构造一个新的 SliceHeader 值。
slice 截取操作为什么不会分配堆内存
因为切片变量本身就是值类型（三字段结构体），s[i:j] 是对这个结构体的拷贝，不是指针解引用。编译器直接在栈上生成新 header：新 Data 指向原数组第 i 个元素地址，len = j - i，cap = cap(s) - i（前提是未越界）。
- 旧版 Go（1.0 前）确实要堆分配
*SliceHeader，但早已废弃 - 当前所有主流版本（≥1.0）都走栈上值拷贝路径，哪怕你写
s[0:len(s)]也零开销 - 你可以用
unsafe.Sizeof(s)验证：64 位系统恒为 24 字节，和截取无关
截取后 cap 计算容易出错的地方
cap 不是“底层数组总长度减去起始索引”，而是“从新 Data 开始到底层数组末尾的可用元素数”。它取决于原始切片的 cap，而非底层数组长度。
- 若
s := make([]int, 5, 10)，则s[2:4]的cap是10 - 2 = 8，不是5 - 2 = 3 - 若
s := arr[1:4]（arr是长度为 10 的数组），则s的cap是10 - 1 = 9，因为底层数组从&arr[0]开始，而新Data是&arr[1] - 错误假设
cap(s[i:j]) == len(s) - i会导致后续append行为误判——实际可追加空间可能远大于此
共享底层数组带来的副作用怎么确认
截取后的新切片与原切片共用同一段内存，修改其中任一元素都会反映到另一方。这不是 bug，而是设计使然，但容易被忽略。
- 用
fmt.Printf("%p", &s[0])和fmt.Printf("%p", &sub[0])可直观对比首元素地址是否相同 -
reflect.ValueOf(s).Pointer()返回的是Data字段值，也能验证是否指向同一块内存 - 想切断共享？必须显式复制：
newSlice := append([]int(nil), s...)或copy(dst, src) - 注意：
make([]int, len(s))后copy才安全；只make不copy仍是空切片，不共享但也没数据
真正麻烦的不是截取本身，而是后续对 cap 的误读和对共享内存的无意识修改——这两点在并发或函数传参时尤其危险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
