预分配 slice 容量更快，因避免 append 频繁扩容带来的内存分配与数据复制开销；已知长度时用 make([]t, 0, n)，有上限时用 caphint，比从空 slice 开始 append 更高效。
为什么预分配 slice 容量比用 append 反复扩容更快
go 中 append 在底层数组满时会触发扩容：通常按 1.25 倍增长（小容量）或翻倍（大容量），并拷贝旧数据。频繁扩容带来冗余内存分配和复制开销。
- 若已知最终长度（如遍历固定大小集合、解析定长协议字段），直接用
make([]T, 0, n)预分配容量，避免任何扩容 - 若长度不确定但有合理上限，用
make([]T, 0, capHint)，再配合append；比从空 slice 开始 append 更可控 - 注意：预分配
make([]T, n)会初始化 n 个零值，若后续要全部覆盖，用make([]T, 0, n)更省初始化成本
何时该用数组（[N]T）而不是 slice（[]T）
数组是值类型，长度固定且编译期可知；slice 是引用类型，含指针、长度、容量三元组。性能差异集中在栈/堆分配与拷贝开销上。
- 小尺寸、固定长度、生命周期短的场景（如坐标
[3]float64、哈希摘要[32]byte）优先用数组——它可完全分配在栈上，无 GC 压力，传参是整体拷贝但成本极低 - 函数参数接收小数组时，直接写
func f(x [4]int)比func f(x []int)更明确且避免隐式切片转换开销 - 慎用大数组（如
[1024]int）作参数或局部变量，栈空间可能溢出，此时 slice + 预分配更稳妥
copy 和 append 在批量操作中的取舍
两者都用于数据搬运，但语义和底层行为不同： copy 是内存块级平移，不检查目标容量；append 是逻辑追加，自动处理扩容。
- 目标 slice 容量已知充足（如预分配好），用
copy(dst[i:], src)—— 零额外分配，无长度检查，纯 memcpy 级别效率 - 需动态增长目标容器，或源数据长度不确定，坚持用
append(dst, src...)；但确保 dst 已有足够容量，否则每次调用都可能触发扩容 - 避免
append(dst[:0], src...)这类“清空再填”写法：它虽重用底层数组，但dst[:0]会丢失原容量信息，导致后续 append 误判容量而扩容
避免 slice 头部截断导致的内存泄漏
slice 截取（如 s = s[1:]）只改变头指针和长度，底层数组仍被整个引用。若原 slice 很大，仅用几个元素却长期持有 slice 变量，会导致本可回收的大内存滞留。
立即学习“go语言免费学习笔记（深入）”；
- 若截取后需长期持有，且原底层数组远大于当前需求，显式复制到新 slice：
s = append([]T(nil), s[1:]...)或s = append(make([]T, len(s)-1), s[1:]...) - 在函数返回局部 slice 时尤其注意：不要返回由大 slice 截取而来的小 slice，除非你确认调用方不会长期持有它
- 用
runtime/debug.ReadGCStats或 pprof 观察 heap profile，若发现大量未释放的大型底层数组，很可能就是 slice 截断泄漏
实际优化中，最常被忽略的是「容量意识」：很多性能问题不是出在算法，而是开发者没意识到自己创建的 slice 正在反复扩容，或无意间持有了一个巨型底层数组的窄视图。