reslice 后底层数组共享是设计特性而非 bug；s2 := s1[2:5] 使 s2 与 s1 共享底层数组，修改 s2[0] 即修改 s1[2]，仅当 append 触发扩容时才断开共享。
reslice 后的底层数组共享是默认行为，不是 bug
当你写 s2 := s1[2:5]，s2 和 s1 会共用同一块底层数组——这不是意外，而是设计使然。只要没触发扩容，改 s2[0] 就等于改 s1[2]。
- 常见错误现象：
s1 := []int{1,2,3,4,5}; s2 := s1[1:3]; s2[0] = 99→s1变成[1,99,3,4,5] - 使用场景：高效构建子视图（如解析协议头、分页读取）、避免拷贝大数组
- 关键判断点：看
cap(s2)是否足够支撑后续append；若不够，扩容后就断开共享 - 性能影响：零分配，纯指针+整数运算，比
copy快得多
append 导致 reslice 失效的临界点在 cap 耗尽时
append 不修改原 slice，只返回新结构体；是否继续共享，取决于扩容与否。一旦 len 超过当前 cap，就会分配新底层数组。
- 常见错误现象：
s1 := []int{0,1,2,3,4}; s2 := s1[3:4]; s2 = append(s2, 5); s2 = append(s2, 6)→ 第二次append后，s1不再被修改 - 参数差异：
append(s2, x)中的s2是 reslice 得来的，它的cap是从原切片起始位置算到数组末尾，不是从s2[0]开始的长度 - 验证方法：打印
len(s2), cap(s2), &s2[0], &s1[0]，观察地址是否一致、容量是否被“截短”
想彻底隔离 reslice 数据，必须显式 copy
仅靠 s2 := make([]T, len(s1)) 或 s2 := s1[:] 都不能切断共享；只有 copy 或重新 make + append 才行。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：
s2 := make([]int, len(s1)); copy(s2, s1)或s2 := append([]int(nil), s1...) - 容易踩的坑：
s2 := s1[1:3]然后直接传给并发 goroutine 写入 —— 竞态风险极高 - 兼容性注意：nil 切片可安全传给
copy，但不能对nil做s2[i] = x
reslice 的 low:high 边界必须落在原 cap 范围内
s[low:high] 要求 0 ≤ low ≤ high ≤ cap(s)，不是 len(s)。越界 panic 提示里写的 “index out of bounds” 实际常是 cap 超限。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：
s := make([]int, 3, 10); s2 := s[5:8]→ panic:slice bounds out of range [:8] with capacity 10（注意提示含capacity） - 调试技巧：出错时立刻打印
len(s), cap(s), low, high，确认high是否 ≤cap(s) - 安全写法：用
s = s[:cap(s)]先“拉满”容量视图，再从中截取，避免隐式 cap 缩减
cap 计算方式和 append 是否扩容之间的耦合关系——它不看 len，只看当前结构体里的 cap 字段值，而这个值由原始切片和截取起始位置共同决定。 
