len 返回切片当前元素个数，cap 返回底层数组从切片起始位置到末尾的长度；二者相等说明切片已用满底层数组，不等则仍有预留空间供 append 复用。
len 和 cap 在切片上返回什么，为什么有时一样有时不一样
切片的 len 是当前可访问元素个数，cap 是底层数组从切片起始位置到末尾的总长度。二者相等，说明切片用满了底层数组空间；不等，说明还有“预留位”——这是 append 不分配新内存的前提。
-
cap不是“容量上限”的模糊概念，而是明确的、可计算的整数：若切片由make([]int, 3, 5)创建，则len是 3，cap是 5 - 对切片做
s = s[1:3]后，len变为 2，但cap可能变成 4（原 cap=5，起始偏移+1，剩余长度=4） - 误把
cap当作“还能 append 多少次”来用会出错：如果底层数组已被其他切片引用，append超过cap时会分配新数组，旧引用数据不再同步
copy 函数怎么安全地在切片间搬运数据，常见崩溃原因
copy 不是深拷贝工具，它只按字节复制源中「最多 min(len(src), len(dst))」个元素。目标切片必须已初始化且有足够长度，否则 panic 或静默截断。
- 目标切片为空（
nil）或未分配空间，copy返回 0 且不报错，但什么也没发生——要先用make配置好dst - 源和目标重叠时（比如
copy(s[1:], s)），行为是定义良好的：按从左到右顺序复制，等效于 memmove，不是 memcpy - 不要用
copy处理结构体切片并期望字段级深拷贝：它只复制结构体值本身（含指针字段的地址），不会递归复制指针指向的内容 - 示例：
dst := make([]int, 3); n := copy(dst, []int{1,2,3,4,5})→n == 3，dst变成[1 2 3]
len 对 map 和 channel 的意义完全不同，误用会导致编译失败
len 可用于 map 和 channel，但 cap 和 copy 完全不支持它们——对 map 调用 cap 会编译报错：invalid argument ... (type map[string]int) has no field or method cap。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
len查 map 返回键值对数量，是 O(1) 操作；查 channel 返回当前缓冲区中元素个数（非阻塞读/写能力），也是 O(1) - 对 channel 使用
copy会直接编译失败：Go 类型系统禁止将 channel 作为copy的参数 - 对 map 使用
copy同样非法，但错误信息更隐蔽：类型不匹配（[]Tvsmap[K]V），容易误以为是泛型问题 - 注意：map 的
len结果不保证并发安全，多 goroutine 写 map 时，即使只读len也可能 panic（因为 map 正在扩容或被修改）
数组上用 len/cap 的陷阱：类型固定，不能像切片那样“伸缩”
数组是值类型，len 和 cap 都返回其声明长度，且不可变。把数组传给函数时，它会整体复制——这不是性能优化点，而是易被忽略的开销来源。
立即学习“go语言免费学习笔记（深入）”；
- 声明
var a [1000]int，len(a)永远是 1000；即使只用了前 5 个元素，它仍占 8KB（假设 int64）内存 - 数组不能直接
append，也不能用copy“扩展”自身；想动态管理就得转成切片：s := a[:]，此时len(s) == cap(s) == 1000 - 函数参数写
func f(a [1000]int)和func f(a [5]int)是两个不同签名，无法用同一函数处理不同长度数组——必须用切片[]int - 小数组（如
[4]byte）适合做 key 或 struct 字段；大数组尽量避免值传递，改用指针或切片
真正麻烦的不是记不住规则，而是当切片底层共享、append 触发扩容、多个变量指向同一底层数组时，len/cap 看似没变，数据却意外被覆盖。这种问题不会报错，只会在某个深夜的测试 case 里悄悄出现。
