copy函数复制元素个数由min(len(src), len(dst))决定，目标切片长度（len）起决定作用而非容量（cap）；必须预先分配足够长度，否则多余元素静默丢弃。
copy 函数到底复制什么：源和目标的长度谁说了算
copy 不是“把源切片全部塞进目标”，它只复制 min(len(src), len(dst)) 个元素。目标切片容量（cap）再大也没用，起作用的是它的长度（len）。常见错误是误以为 copy(dst, src) 能自动扩容 dst —— 它不会，dst 必须预先分配好足够长度的空间，否则多余元素被静默丢弃。
典型误用场景：
- 目标切片是 nil 或 len=0：
copy([]int{}, src)返回 0，什么都没复制 - 目标长度不足：
dst := make([]int, 2)去 copy 长度为 5 的 src，只复制前 2 个 - 用 cap 当 len 用：
dst := make([]int, 0, 10)，此时 len(dst) 是 0，copy仍返回 0
安全复制的三步写法：预分配 + 检查 + copy
真正安全的做法不是靠 copy 自己兜底，而是主动控制源头和目标的状态。最简健壮模式如下：
src := []string{"a", "b", "c"}
dst := make([]string, len(src)) // 步骤1：按需分配等长目标
n := copy(dst, src) // 步骤2：执行复制
if n != len(src) { // 步骤3：校验是否全量复制成功
log.Printf("warning: only copied %d of %d elements", n, len(src))
}
注意点：
立即学习“go语言免费学习笔记（深入）”；
- 始终用
make([]T, len(src))，而不是make([]T, 0, len(src)) - 如果目标切片已存在且可能复用，先确保
len(dst) >= len(src)，否则 panic 或截断 - 对空切片也要处理：
if len(src) == 0 { dst = []T{} }，避免 make(0) 后 copy 报错（虽然不会 panic，但逻辑易错）
copy 和 append 的边界在哪：什么时候该换用 append
当目标切片需要「追加」而非「覆盖式复制」时，copy 就不是最佳选择。append 会自动扩容，语义更清晰，且能复用底层数组（如果容量够）。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
比如拼接两个切片：
// ❌ 不推荐：手动管理长度、易出错 dst := make([]int, len(a)+len(b)) copy(dst, a) copy(dst[len(a):], b) // ✅ 推荐：一行解决，自动处理 dst := append(a[:len(a):len(a)], b...)
关键区别：
-
copy是内存级覆盖，不改变目标底层数组引用关系 -
append可能分配新底层数组，但对使用者透明；若要强制复用原数组，得用a[:len(a):cap(a)]形式限制容量 - 性能上，两者在不触发扩容时接近；但
append更少出错，尤其涉及动态增长时
类型不匹配时的隐式转换陷阱
copy 要求源和目标切片元素类型必须底层类型相同，不能靠 interface{} 或类型别名绕过。例如：
type MyInt int
var a []int = []int{1, 2}
var b []MyInt = make([]MyInt, 2)
copy(b, a) // ❌ compile error: cannot use a (type []int) as type []MyInt
这种错误不会在运行时报 panic，而是在编译期直接失败。解决方法只有显式转换：
- 逐元素赋值（小数据量可接受）
- 用
unsafe.Slice（Go 1.17+，仅限底层类型完全一致且你清楚风险） - 用反射（通用但慢，一般不必要）
最容易被忽略的是字符串转字节切片：copy(dst, []byte(s)) 是合法的，因为 []byte 和 []uint8 底层类型相同；但 copy(dst, s) 直接传 string 会编译失败 —— copy 不接受 string 作为参数，必须显式转成 []byte。
