copy函数复制时只取min(len(dst), len(src))，需确保dst长度足够且非nil；重叠复制行为未定义，应避免；深拷贝嵌套结构需递归copy；安全复制用make+copy或append([]T(nil), s...)。
copy 函数怎么用才不会丢数据
直接用 copy 复制切片时，目标切片长度不够就会 silently 截断——不是 panic，而是默默丢掉超出部分。常见错误是把空切片当目标：dst := []int{}，结果 copy(dst, src) 返回 0，什么都没复制进去。
正确做法是确保目标切片容量足够，且用 make 预分配：
src := []int{1, 2, 3, 4, 5}
dst := make([]int, len(src)) // 注意：是 len，不是 cap
n := copy(dst, src) // n == 5，dst 现在是 [1 2 3 4 5]
-
copy(dst, src)实际复制数量 =min(len(dst), len(src))，只看长度，不看容量 - 如果 dst 是
nil，copy返回 0，不 panic，但也不做任何事 - 想深拷贝嵌套结构（比如
[][]int），copy只复制外层数组头，内层 slice 仍共享底层数组
用切片截取（[:len]）复制是否安全
写 newSlice := oldSlice[:len(oldSlice)] 看似“复制”，其实只是创建新 slice header，指向同一底层数组——改 newSlice[0] 就等于改 oldSlice[0]。这不是复制，是别名。
真正安全的截取复制只有一种场景：你明确需要共享底层、且后续只读。否则就是隐患。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 误用示例：
b := a[:]; b[0] = 999→a[0]也变成 999 - 若要隔离修改，必须配合
make + copy，或使用append([]T(nil), a...)这种惯用法（它会分配新底层数组） -
append([]int(nil), s...)效率略低于make+copy，但代码更短，且语义清晰：“我要一个值相同但独立的新切片”
性能对比：make+copy vs append(nil, ...) vs 切片字面量
三者语义不同，不能混用。切片字面量（如 []int{1,2,3}）是编译期确定的静态构造，和运行时复制无关；真正可比的是前两者。
-
make([]T, len(s)) + copy：两步操作，但内存分配和复制分开，可控性强；适合已知长度且需复用 dst 的场景 -
append([]T(nil), s...)：一步到位，内部会调用growslice分配带冗余容量的新数组，对小切片有轻微开销，但代码简洁无错漏风险 - 基准测试显示，1000 元素以内差异可忽略；超过 10k 元素时，
make+copy稳定快 10%~15%，因为避免了 append 的容量检查与可能的 double-cap 扩容
容易被忽略的边界：copy 源和目标重叠时的行为
当源和目标切片共享底层数组且有重叠时，copy 的行为是「从左到右按顺序复制」，可能导致中间结果污染。例如：
a := []int{1,2,3,4,5}
copy(a[1:], a[:4]) // 想右移？结果是 [1,1,2,3,4]
这不像 memmove，copy 不保证重叠安全。Go 文档明确说：“如果源和目标重叠，行为未定义”。实际中它按升序拷，所以目标起始位置必须 ≥ 源结束位置，否则出问题。
- 安全重叠复制（如实现循环移位）必须手动分段，或用
reflect.Copy（不推荐） - 绝大多数业务代码应避免源目标重叠；若真需要，先判断
&a[0] == &b[0]和区间关系，再决定是否分步 - 这个细节在单元测试里很难覆盖，上线后才暴露——建议把重叠 copy 当作 bug 来 lint
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
