Go copy返回长度小于预期时的切片容量分析

Go 里调用 copy(dst, src) 后，返回长度小于预期，最常见的原因不是数据丢失，而是把切片的 cap 当成了可写长度。copy 实际复制的元素数量等于 min(len(dst), len(src))。因此目标切片即使有更大的容量，只要当前 len(dst) 较小，复制就会在这个长度处停止。

先按 len(dst) 判断 copy 上限

下面这个例子故意让目标切片长度为 0，但容量为 4。容量看起来足够，实际目标却没有任何可见元素，所以返回值仍然是 0。

package main

import "fmt"

func main() {
	src := []int{10, 20, 30, 40}
	dst := make([]int, 0, len(src)) // 中文注释：只预留容量，当前长度仍然是0
	n := copy(dst, src)              // 中文注释：copy只按目标当前长度计算可写范围
	fmt.Println(n, len(dst), cap(dst), dst) // 中文注释：输出0 0 4 []
}

排查时先打印 len(src)、len(dst) 和 cap(dst)。如果目标长度为 0，返回 0 是符合语言规则的结果；如果目标长度为 2，最多只能复制 2 个元素。

len 决定可见范围，cap 只决定可扩展上限

切片可以看成指向底层数组的一组描述信息：起始位置、当前长度和容量。len 是当前代码允许访问的元素数量，cap 是从当前起点继续切片时可使用的底层数组范围。两者满足 0 ，但职责不同。

所以“容量够但 copy 返回 0”并不矛盾。容量只说明底层数组有空间，不能替代目标切片的当前长度，也不会让 copy 隐式调用 append。

用目标长度承接完整复制

如果目标就是接收全部源数据，直接把目标长度设为源数据长度，代码最清楚：

src := []int{10, 20, 30, 40}
dst := make([]int, len(src)) // 中文注释：长度决定copy本次可写入的元素数
n := copy(dst, src)          // 中文注释：源和目标长度相同，返回4
fmt.Println(n, dst)           // 中文注释：输出4 [10 20 30 40]

如果业务先分配了零长度缓冲区，也可以在容量范围内重新切片。这里的前提是新长度不能超过容量：

src := []int{10, 20, 30, 40}
buffer := make([]int, 0, len(src)) // 中文注释：先保留底层数组，但暂时没有可见元素
dst := buffer[:len(src)]           // 中文注释：把可见长度扩展到容量以内
n := copy(dst, src)                // 中文注释：现在目标有4个可写位置
fmt.Println(n, dst)                // 中文注释：输出4 [10 20 30 40]

若目标长度只是协议允许的前缀长度，就不要为了追求返回值等于源长度而盲目扩容。此时返回值小于源长度反而是正常的截断信号，调用方应根据 n 决定是否继续处理。

重叠复制和空切片的判断清单

copy 支持源和目标共享底层数组，重叠区域可以安全复制，结果相当于先读取再写入，不需要手工倒序。但这不改变长度上限，仍然按两个切片的 len 取最小值。

nil 切片的长度和容量都是 0，把它作为源或目标复制不会产生元素；这通常是安全的，但不能把它当成已经分配好的缓冲区。需要承接数据时，应明确使用 make 或 append。

最后按下面顺序复查：第一，源数据是否真的有长度；第二，目标 len 是否为预期数量；第三，是否误把 cap 当作可写长度；第四，复制后是否使用了返回的 n 截取有效结果。这样既能修复返回值偏小，也能避免把未写入的零值误当成复制结果。

常见问题

为什么 make([]int, 0, 10) 不能复制 10 个元素？

因为它的长度是 0，当前没有可写元素；容量只允许你之后把切片重新切长到不超过 10。

copy 会自动扩大目标切片吗？

不会。需要自动增长时使用 append；需要固定目标时先用正确长度创建或重切片。

返回值小于 len(src) 一定是错误吗？

不一定。目标切片本来就可能只接收前缀，返回值只是实际复制数量，是否异常要结合业务边界判断。