预分配容量避免多次扩容拷贝，make([]int, 0, 100) 零拷贝，[]int{} 可能触发8次扩容；复用切片应重置len而非重新make，保留底层数组。
为什么 make([]int, 0, 100) 比 []int{} 更快？
因为预分配容量避免了多次底层数组扩容。Go 的切片在 append 时，若当前容量不足，会触发内存重新分配 + 数据拷贝（时间复杂度 O(n)）。从空切片开始追加 100 个元素，可能经历 0→1→2→4→8→16→32→64→100 共 8 次扩容；而预设 cap=100 后，全程零拷贝。
- 永远优先用
make([]T, 0, expectedCap)初始化可增长切片，而非字面量[]T{} - 若确切知道最终长度且不增删，直接用数组
[100]int—— 零分配、栈上分配（小数组）、无指针逃逸 - 注意：
make([]T, n)是初始化长度为n的切片（前n个元素已存在），不是预分配容量；要预分配请显式写第三个参数
如何安全复用切片避免频繁分配？
高频循环中反复创建切片是 GC 压力主因之一。复用的关键是：保留底层数组引用，仅重置长度（len），不改变容量（cap）。
var buf []byte
for i := 0; i < 1000; i++ {
buf = buf[:0] // 重置长度为 0，底层数组不变
buf = append(buf, 'h', 'e', 'l', 'l', 'o')
// ... 使用 buf
}
- 切忌写
buf = []byte{}或buf = make([]byte, 0)—— 这会丢弃原底层数组，触发新分配 - 复用前提：确保每次使用后不会保留对旧
buf的引用（如传给 goroutine 或存入 map），否则数据竞争或脏读 - 对类型不确定的场景，可用
sync.Pool管理切片对象，但注意 Pool 中的对象无序、不可预测生命周期
copy 与切片截取哪个更适合子序列提取？
取决于是否需要隔离底层数据。截取（s[a:b]）只是共享底层数组的视图，零拷贝但有副作用风险；copy 创建独立副本，安全但有开销。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果后续只读、且父切片不会再修改 → 直接截取，例如日志解析中提取 token：
token := line[5:10] - 如果要传递给其他函数/协程，或父切片很快被重用 → 必须
copy：dst := make([]byte, len(src)) copy(dst, src)
- 注意：
copy(dst, src)实际复制长度为min(len(dst), len(src))，别假设全量复制成功
数组传参为什么有时比切片更高效？
小数组（如 [16]byte）作为函数参数时按值传递，编译器常将其优化为寄存器传参或栈内联；而切片是三字宽结构体（ptr+len+cap），虽也是值传递，但其中 ptr 指向堆内存，间接访问成本更高。
立即学习“go语言免费学习笔记（深入）”；
- 适合场景：固定长度、尺寸 ≤ 几十个字节、内容只读或需强隔离（如加密 key、哈希摘要）
- 反例：传
[1024]int—— 栈空间爆炸，强制逃逸到堆，性能反而更差 - 验证方式：加
-gcflags="-m"编译，看是否出现... escapes to heap
