copy函数不是零拷贝，而是内存块复制，其核心价值在于绕过append的扩容逻辑：预分配目标切片容量后，copy可一次性批量搬运数据，避免反复len/cap判断、扩容决策及底层数组复制，大幅提升大批量写入性能。
copy函数不是零拷贝，但能绕过append的扩容逻辑
很多人误以为copy是“零拷贝”，其实它只是内存块复制（底层调用memmove），不分配新底层数组，也不触发扩容检查。真正价值在于：当你已经预分配好目标切片容量时，copy能跳过append每次都要做的len/cap判断、扩容决策和可能的底层数组复制——这在大批量写入时省掉大量分支和内存操作。
常见错误是直接copy(dst, src)却不保证dst容量足够：copy只按len(src)和cap(dst)的较小值复制，超出部分静默丢弃，且不报错。
- 必须提前用
make([]T, 0, N)或make([]T, N)分配目标容量，N >= len(src) - 若目标切片是复用的（比如来自
sync.Pool），记得先重置长度：dst = dst[:0]再copy -
copy不改变目标切片的len，所以复制后要手动截断：dst = dst[:len(src)]或dst = dst[:n]（n是copy返回值）
大切片场景下，copy比循环append快得多
对长度已知的源切片（如从DB查出的[]User、网络包解析后的[]byte），用for循环+append会反复触发扩容逻辑，尤其当初始容量不足时，小切片翻倍、大切片加25%，中间伴随多次runtime.growslice调用和数据搬移。
而copy是一次性批量搬运，底层由编译器优化为高效汇编指令，没有循环开销，也没有每次追加都要检查容量的分支跳转。
- 正确写法：
dst := make([]int, len(src)); copy(dst, src) - 错误写法：
for _, v := range src { dst = append(dst, v) }（即使dst已预分配，append仍做冗余检查） - 性能差异在pprof中明显：前者
runtime.slicecopy占主导；后者runtime.growslice和runtime.makeslice频繁出现
copy无法解决底层数组共享问题，别指望靠它隔离修改
copy只做浅拷贝：结构体字段里的*T、map、chan、[]T这些值（即指针、header）被复制过去，但它们指向的数据仍在原底层数组或堆上。这意味着，如果你复制的是含指针字段的结构体切片，后续修改新切片里某个结构体的指针字段所指向的内容，原切片看到的仍是同一份数据。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
更隐蔽的坑是：目标切片本身可能和别的变量共享底层数组。比如你从一个大缓冲buf里取子切片buf[i:j]再copy进去，新切片仍和buf共用底层数组——这不是copy的问题，而是你没用make新建独立底层数组。
- 确保物理隔离：必须
dst := make([]T, len(src))，而不是dst := src[:len(src)]或dst := append([]T(nil), src...) - 结构体含指针？
copy不够，得手写深拷贝逻辑或用encoding/gob等序列化方式 - 安全起见，打印
&dst[0]和&src[0]地址对比，确认不相等
大容量预分配+copy组合，才是高频写入的稳态方案
单纯用copy还不够。真正的优化闭环是：预分配 → 复用 → copy → 截断 → 归还。尤其在服务端高频处理网络包、日志批写、序列化输出等场景，这套组合能压住GC压力和内存抖动。
例如，一个HTTP服务每秒处理上千个JSON响应体，每个响应约2KB。如果每次都make([]byte, 0, 2048)再json.Marshal，不仅分配频繁，Marshal内部还会因容量不足再次扩容。换成预分配+copy视图写入，性能提升显著。
- 全局池定义：
var bufPool = sync.Pool{New: func() any { return make([]byte, 0, 4096) }} - 使用时：
buf := bufPool.Get().([]byte); buf = buf[:cap(buf)]; n := copy(buf, data); buf = buf[:n] - 用完归还：
bufPool.Put(buf[:0])（注意是[:0]，不是nil） - 关键点：预分配容量要略大于典型负载，但别过度（如实际平均1.8KB，预设4KB比16KB更优）
复杂点在于边界控制——copy不校验容量，sync.Pool不保序，make的cap和len关系容易混淆。这些地方一松懈，就退回成带隐式扩容的老写法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
