Go语言内建函数copy的使用：语言学习中的切片元素迁移-Golang-PHP中文网

copy(dst, src)参数顺序易写反，因与多数go写入操作相反但符合c惯例；写反后复制0元素且不报错，需人工校验、检查返回值、确保dst长度足够、注意浅拷贝和重叠风险。

go语言内建函数copy的使用：语言学习中的切片元素迁移

copy(dst, src) 参数顺序为什么总写反？

因为 Go 里绝大多数 “写入” 操作（比如 os.Write、io.WriteString）都按 “dst, src” 顺序，但 copy 是个例外——它和 C 的 memcpy 一致，也和多数系统级 API 一样：先目标，后源。可偏偏初学者常类比 os.Copy（它确实是 dst, src），结果写成 copy(src, dst)。

这种写错不会 panic，但几乎一定复制 0 个元素：因为 src 长度通常远小于 dst，而 copy 只取 min(len(dst), len(src))。现象是 dst 看起来“没变”，调试时还怀疑逻辑或并发问题。

IDE 开启参数提示，或手动加注释：// copy(dst, src)
用 gofmt 或 go vet 无法捕获，得靠人工校验
如果真想“把 dst 覆盖成 src”，就该写 copy(dst, src)；反之，写反了就是“把 src 当目标覆盖”，基本无效

目标切片长度不够，copy 返回 0 却不报错

copy 不分配内存，只搬运已有空间里的元素。所以 dst 若是 []int{}、nil 或 make([]int, 0)，它的 len 就是 0，copy 直接返回 0 —— 不 panic，也不 warning。

常见错误写法：var dst []int; copy(dst, src)，结果 dst 还是空；或者 dst := make([]int, 3) 但 src 长 5，只复制前 3 个，后 2 个丢掉，还误以为“复制成功”。

安全做法：用 make([]T, len(src)) 明确分配长度匹配的目标切片
务必检查返回值：n := copy(dst, src); if n != len(src) { log.Printf("warning: only %d of %d copied", n, len(src)) }
别依赖 len(dst) == 0 判断是否初始化过——make([]int, 0, 100) 的 len 也是 0，但它有容量，能 append，却不能直接 copy

copy 对嵌套结构只是浅拷贝，改一个 map 全崩了

copy 的本质是内存块拷贝，对每个元素做 memmove。如果元素是 int、string、[3]byte 这类值类型，没问题；但一旦是 *T、map[string]int、[]byte 或含指针字段的 struct，它只复制 header 或地址，不复制背后的数据。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

典型翻车现场：original := [][]int{{1,2}, {3,4}}; copied := make([][]int, len(original)); copy(copied, original)。此时 copied[0] 和 original[0] 指向同一底层数组，改 copied[0][0] 就等于改 original[0][0]。

纯值类型切片（如 []int、[]byte）：放心用 copy，快且安全
含引用类型元素的切片：必须遍历 + 显式构造新实例，例如 copied[i] = append([]int(nil), original[i]...) 或深拷贝逻辑
结构体切片若含指针字段，copy 后两个切片的 struct 字段地址相同，共享状态 —— 这不是 bug，是设计使然

重叠复制时行为看似安全，但逻辑容易绕晕

copy 支持源和目标切片重叠（比如同一底层数组内移动），底层调用 memmove，所以不会因覆盖出错。但方向决定结果：从左往右逐个赋值，意味着 copy(s[i:], s[j:]) 在 i 时安全；若 <code>i > j 且重叠，旧值可能被提前覆盖，导致数据丢失。

最常用场景是删除中间元素：s = append(s[:i], s[i+1:]...) 底层就靠 copy(s[i:], s[i+1:]) 实现搬移。但如果手写错索引，比如 copy(s[3:], s[1:]) 且 len(s) == 5，就会把 s[1] 覆盖到 s[3]，再把 s[2] 覆盖到 s[4]，原 s[3]、s[4] 彻底消失。