会，append 可能复用原底层数组导致其他引用该数组的切片“看似被修改”；它返回新切片头，原变量不变，需显式赋值接收，且向 nil 切片 append 安全高效。
append 会修改原切片吗？
不会直接修改——但可能复用底层数组，导致“看似被改”的副作用。这是最常踩的坑：你以为追加只影响当前变量，结果另一个引用同一底层数组的切片也变了。
根本原因是 append 返回新切片头（包含新的长度和可能的新底层数组指针），而原变量没变；但如果容量够，它会往原数组末尾写，其他共享该数组的切片就能看到变化。
- 判断是否扩容：比较
len(s)和cap(s)，len(s) == cap(s)时必扩容 - 想确保隔离：追加前用
make([]T, 0, len(s))拷贝一份再操作 - 调试技巧：打印
&s[0]（取首元素地址）可快速验证是否共用底层数组
向 nil 切片 append 安全吗？
完全安全，且是 Go 推荐做法。nil 切片的长度、容量都是 0，append 内部会自动调用 make 分配底层空间。
常见错误是手动初始化空切片：s := []int{} 或 s := make([]int, 0)，其实没必要——除非你明确要指定初始容量。
-
var s []int是最轻量的 nil 切片声明方式 -
append(s, 1, 2, 3)对 nil 切片有效，返回长度为 3 的新切片 - 性能差异：nil 切片首次 append 的分配开销 ≈
make([]int, 0, 1)，但省去显式声明更清晰
一次 append 多个元素怎么写？
直接在 append 后面列出来就行，不用包装成切片（除非来源本身就是切片）。语法简单，但参数顺序和展开逻辑容易混淆。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键区别在末尾有没有 ...：不带是逐个值插入；带是把一个切片“打散”后插入。
- 追加字面量：
append(s, 1, 2, 3)→ 插入三个 int - 追加另一切片：
append(s, otherSlice...)→...必须紧贴变量名，不能写成append(s, ...otherSlice) - 错误写法：
append(s, []int{1,2,3})会报类型错误，因为传了切片而非多个 int
为什么 append 后原变量没变？
因为切片是值传递：每次赋值或传参都复制 header（指针、长度、容量），不是复制底层数组。所以 append 返回的是新 header，必须显式接收。
典型症状是写了 append(s, x) 却没赋值，结果 s 还是旧的——编译器甚至会警告 “result of append not used”。
- 正确写法：
s = append(s, x)或s = append(s, x, y) - 函数内修改需返回：
func add(s []int, x int) []int { return append(s, x) } - 别依赖副作用：Go 没有类似 Python
list.append()的就地修改方法
底层数组复用和 header 值传递这两点，决定了所有 append 行为的边界。不理解它们，光记语法迟早掉坑里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
