Go中slice高级用法源于实践踩坑：预分配需append生效；三索引k是底层数组截止索引；copy不改变dst长度；slice值传递可改元素但不可扩容，须返回新切片。
slice 的高级用法不是靠背概念记住的，而是在真实读写、传参、扩容场景里踩坑后自然形成的直觉。下面这几种情况，几乎每个 Go 开发者都遇到过，也最容易写错。
用 make([]T, 0, n) 预分配容量却忘了后续 append 才生效
很多人以为 make([]int, 0, 100) 创建出来就“预留了 100 个位置”，其实它长度是 0，什么元素都没有。真正触发预分配效果的是后续的 append ——只要不超容量，就不会 realloc。
- 错误写法：
buf := make([]byte, 0, 1024); buf[0] = 'a'→ panic: index out of range - 正确写法：
buf := make([]byte, 0, 1024); buf = append(buf, 'a')→ 安全，且零拷贝 - 适用场景：构建 HTTP 响应体、序列化 JSON、拼接日志行等已知上限的缓冲场景
- 不适用场景：需要随机写入中间位置（比如填空式构造），这时得用
make([]T, n)先占位
用 s[i:j:k] 三索引语法时搞错 k 的含义
k 不是“最大长度”，而是底层数组的截止索引，即 cap(result) == k - i。写成 s[1:3:5] 意味着结果切片最多还能 append 2 个元素（因为 5-1==4，当前长度是 2，剩余容量为 2）。
- 常见误判：
src := []int{0,1,2,3,4,5}; sub := src[2:4:4]→cap(sub)是 2，不是 4 - 典型用途：封装函数返回值，防止调用方用
append意外污染原始数据 - 坑点：如果
k > cap(src)，会直接 panic，Go 不做隐式截断 - 调试技巧：打印
len(sub), cap(sub), &sub[0], &src[0]能立刻看出是否共享内存
用 copy 替代 append 时没注意目标切片长度
copy(dst, src) 只复制 min(len(dst), len(src)) 个元素，且只动 dst 已有长度范围内的位置——它不会改变 dst 的长度，也不会自动扩容。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：
dst := make([]int, 0, 10); copy(dst, []int{1,2,3})→dst仍是空切片，啥都没写进去 - 正确做法：
dst := make([]int, 3); copy(dst, []int{1,2,3})或dst = append(dst, src...) - 适用场景：高性能批量填充（如从 buffer 读取固定长度数据）、避免多次
append触发扩容 - 注意：
copy对 nil 切片 panic，对长度为 0 的切片安全但无效
在函数参数中传递 slice 却误以为修改会影响调用方
切片本身是值传递，但它的底层结构（指针+长度+容量）被复制了。所以你能通过 dst[i] = x 修改原数组内容，但不能靠 dst = append(dst, x) 让调用方看到新切片。
- 能影响原数组：
func mutate(s []int) { s[0] = 999 }→ 调用后原切片首元素真变了 - 不能影响切片头：
func grow(s []int) { s = append(s, 999) }→ 调用方看到的还是旧切片 - 安全做法：需要扩容时，函数必须返回新切片：
func grow(s []int) []int { return append(s, 999) } - 混淆点：
range循环里的value是副本，改它不影响原切片；但index对应的s[index]是原地址
真正卡住人的从来不是语法，而是“为什么改了没生效”或“为什么改了别的地方也变了”。多打几次 fmt.Printf("%p %d %d\n", &s[0], len(s), cap(s))，比看十遍文档管用。
