append容量足够时复用底层数组，导致多个slice共享内存并可能互相覆盖数据，这不是bug而是设计使然；正确做法是显式拷贝或使用slices.clone等安全复制方式。
append 容量足够时会复用底层数组，不是“安全”而是“共享”
很多人以为 append 只要没扩容就“没问题”，其实恰恰相反：容量够 → 复用原数组 → 所有基于同一底层数组的 slice 都可能互相踩内存。这不是 bug，是设计使然。
-
append返回新 slice，但若 cap 足够，array字段（即底层数组指针）和原 slice 完全一致 - 多个
append结果若共享底层数组，写入位置重叠就会覆盖——比如对同一个route := []int{3,7}并发或顺序调用两次append(route, x) - 典型表现：
pathA看起来是[3,7,2]，pathB是[3,7,5]，但打印pathA时发现第三位变成5
make([]T, len, cap) 后用 []T{...} 赋值会丢掉预分配容量
这是高频误用：想预分配空间又图省事直接写 mySlice = []int{1,2,3}，结果 cap(mySlice) 变成 3，白 alloc 了。
Golang Google Wire
下载
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
-
[]int{1,2,3}是复合字面量，等价于新建一个长度为 3 的数组再取其切片，cap必为 3 - 正确初始化方式只有两种：
mySlice[i] = v逐个赋值，或用append(make([]int, 0, 10), 1, 2, 3) - Go 1.21+ 支持三参数切片语法，可强制保留容量：
mySlice = []int{1,2,3}[:3:10]，但注意这仍是新底层数组，不等于原make分配的那块内存
子切片钉住大数组导致 GC 不回收
只要一个子切片还活着，它背后的整个底层数组就无法被 GC 回收——哪怕你只取了前 8 字节，背后可能是 10MB 的 []byte。
- 高危场景：从
http.Request.Body读出完整 body 后取body[12:20]存进context.WithValue；或rows.Scan(&data)后对data[100:120]做缓存 -
s[:]或s[0:len(s)]不切断引用，只是调整len和cap，array指针没变 - 真正安全的做法只有两个：
safe := append([]T{}, s[i:j])（简洁但多一次小分配），或safe := make([]T, j-i); copy(safe, s[i:j])（零额外开销，推荐） - Go 1.20+ 对
[]byte可直接用bytes.Clone()，语义清晰且底层优化过
并发写 slice 必须加锁，append 不是原子操作
append 看似简单，实际包含“检查容量→决定是否扩容→复制/写入→更新 len→返回新 slice”多个步骤，任何一步都可能被其他 goroutine 中断。
- 典型现象：10000 次并发
append(a, i)，最终len(a)小于 10000，甚至 panic（如扩容时另一 goroutine 正在读a的len字段） - 不能靠 “我只读不写” 来免责：只要存在并发读写，就构成数据竞争，go race detector 会报
Data Race on field len - 唯一通用解法：用
sync.Mutex锁住整个 append 操作；或改用 channel 串行化（适合写少读多场景） - 注意：
sync.Slice不存在，别搜这个——Go 标准库没提供线程安全 slice
[]uint8、race detector 报出的模糊栈帧、线上服务缓慢增长的内存占用——这些才是真实战场。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
