应优先使用 copy(dst, src) 而非手动循环赋值，因 copy 由编译器内联为高效内存指令，避免边界检查等开销，性能高 3–10 倍。
直接用 copy 替代循环赋值，性能差 3–10 倍
go 中对切片（[]T）做逐元素循环赋值（如 for i := range dst { dst[i] = src[i] }）是常见但低效的做法。底层 copy 函数由编译器内联为内存块拷贝指令（如 rep movsq），而手写循环无法触发这类优化，且引入边界检查、索引计算和分支预测开销。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 始终优先使用
copy(dst, src)，而非手动循环 —— 它自动处理长度截断、类型兼容性，并在运行时调用最优的 memmove 实现 - 确保
dst已分配足够容量：若len(dst) ，只拷贝前len(dst)个元素，不会 panic - 对固定长度数组（如
[1024]int），需先转为切片再copy：copy(dst[:], src[:])
src := [1024]int{1, 2, 3} dst := [1024]int{} copy(dst[:], src[:]) // ✅ 正确 // copy(dst, src) ❌ 编译错误：数组不支持直接 copy避免隐式数组转切片带来的逃逸和堆分配
声明形如 arr := [1024]int{} 的大数组时，若将其作为参数传给接收 []int 的函数，会触发“数组转切片”操作，导致该数组从栈逃逸到堆 —— 这不仅增加 GC 压力，还破坏了局部性。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对小数组（≤ 128 字节），保持值语义传递，显式传数组指针：
func process(arr *[1024]int)，避免隐式切片转换 - 若必须用切片接口，考虑将大数组定义为全局变量或复用池（
sync.Pool）中管理，防止高频分配 - 用
go tool compile -S检查是否逃逸：./main.go:12:6: arr does not escape表示安全
append 不等于拷贝：误用会导致底层数组共享和意外修改
很多人用 dst = append([]T(nil), src...) 实现“深拷贝”，这看似简洁，但实际行为取决于 src 底层数组是否被复用。当 src 的 cap 足够大且未被其他变量引用时，append 可能直接复用其底层数组 —— 导致 dst 和 src 共享同一段内存。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 需要真正隔离的副本时，明确用
make+copy：dst := make([]T, len(src)); copy(dst, src) - 若只是临时读取，且能保证
src生命周期覆盖使用期，可直接传递切片，不拷贝 - 警惕
append返回的新切片与原切片指向同一底层数组的场景，尤其在并发写入或后续append扩容时
src := []int{1, 2, 3} dst := append([]int(nil), src...) // ❌ 不可靠：可能共享底层数组 dst := make([]int, len(src)); copy(dst, src) // ✅ 明确隔离预分配切片容量比动态增长快 2–5 倍
对未知长度的数据做累积拷贝（如从多个 buffer 合并），若反复用 append 而不预估容量，会触发多次底层数组 realloc 和数据迁移。每次扩容按 1.25 倍增长，早期小 slice 尤其浪费。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 能预估最终大小时，直接
make([]T, 0, estimatedCap)，再用copy或append填充 - 无法预估但有上限（如 http body ≤ 10MB），按上限预分配，避免 runtime 碰撞式扩容
- 对高频小拷贝（如单次 ≤ 64 字节），用栈上数组（
[64]byte）+copy，比堆上切片快一个数量级
数组拷贝的性能陷阱往往不在算法层面，而在你没意识到某次 append 共享了底层数组，或一次隐式切片让大数组逃逸到了堆上。