append 必须返回新切片，因为扩容时底层数组地址变更，原变量仍指向旧内存；切片是ptr/len/cap三元组，值传递下函数内修改不影响外部，不接收返回值将导致使用失效指针、脏数据或panic。
append 为什么必须返回新切片
因为 append 可能触发底层数组扩容，此时旧切片的 data 指针已失效，原变量仍指向旧内存——不返回就无法拿到新地址。
切片本质是三元组：ptr（指向底层数组）、len、cap。扩容时系统 malloc 新数组、复制数据、更新 ptr，但调用者传入的只是值拷贝，函数内修改不影响外部变量。
- 不接收返回值 → 继续用旧切片 → 可能读到脏数据或 panic（如后续再
append超出旧cap） - 即使没扩容，Go 也不保证复用原数组（例如从 nil 切片开始 append）
- 编译器不会报错，运行时行为取决于当前容量和元素数量，极难复现
什么情况下 append 会扩容
扩容触发条件只看 len 和 cap：当 len + 1 > cap 时必须分配新底层数组。
具体策略由运行时决定：小切片通常翻倍，大切片按 1.25 倍增长，但这是实现细节，不可依赖。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
make([]int, 0, 4)再append第 5 个元素 → 必扩容 -
nil切片首次append→ 总是分配新数组（哪怕只加 1 个元素） - 从其他切片
[:]截取而来，cap可能远大于len，此时多次append也不扩容
忽略返回值的典型错误现象
最常见的是循环中反复 append 却不更新变量，导致只有最后一次写入生效，或 panic。
var s []int
for i := 0; i < 3; i++ {
append(s, i) // ❌ 没接返回值，s 始终是 nil
}
fmt.Println(len(s)) // 输出 0
另一个隐蔽问题：在函数参数中传入切片并试图原地修改
func badAdd(s []int, v int) {
append(s, v) // ❌ 外部 s 不变
}
s := []int{1}
badAdd(s, 2)
fmt.Println(s) // [1]，不是 [1 2]
- 错误信息通常是
index out of range或静默丢数据 - 调试时打印
&s[0]会发现地址突变，但没人检查这个 - 用
go vet能捕获部分未使用返回值的情况，但非全部
怎么安全地用 append
唯一原则：永远用返回值覆盖原变量，除非你明确知道当前操作不会扩容且不需要结果。
- 基础写法：
s = append(s, x)或s = append(s, x, y, z) - 批量追加另一个切片：
s = append(s, t...)（注意...不可省略） - 初始化时预估容量可减少扩容次数：
s := make([]int, 0, 100) - 如果真要避免返回值（极少数场景），确保
len(s) 且只追加 1 个元素，但仍建议显式赋值
底层数组是否变更不是你能控制的，是运行时根据当前状态做的决策。依赖“没扩容”来跳过赋值，等于把逻辑建立在沙滩上。
