append 不会修改原切片变量，但若底层数组容量足够，新旧切片共享底层数组，修改新切片元素可能影响原切片；扩容按长度分段处理，并非简单翻倍。
append 会修改原切片吗？
不会——但要看你传进去的是什么。关键在底层数组是否被复用：append 返回新切片，原变量不变；但如果原切片容量够用，返回值和原切片共享底层数组，改新切片的元素可能“意外”影响旧变量。
- 常见错误现象：
slice1 := []int{1,2}; slice2 := append(slice1, 3); slice2[0] = 99; fmt.Println(slice1)输出[99 2]——不是 bug，是共享底层数组的必然结果 - 使用场景：需要链式追加时（如
append(append(a, x), y)），必须用返回值，不能忽略赋值 - 参数差异：第二个参数起支持展开（
append(dst, src...)），但src必须是同类型切片，不能是数组或 interface{}
扩容时机和容量翻倍规则
Go 不是每次 append 都翻倍扩容，而是按当前长度分段处理：小切片（len
- 性能影响：频繁 append 小数据却预估不足，会导致多次底层数组复制（O(n) 每次），实测比预分配慢 3–5 倍
- 兼容性注意：该策略自 Go 1.18 起稳定，但不同版本初始容量计算逻辑微调过，别依赖具体倍数，只依赖“不缩容”和“单调递增”
- 实操建议：已知最终长度时，直接用
make([]T, 0, estimatedLen)预分配；不确定时，宁可略高估，别用make([]T, 0)
append(nil, x) 是安全的吗？
完全安全，且是 Go 官方推荐的初始化惯用法。nil 切片的底层数组指针为 nil、长度和容量都是 0，append 内部会自动分配第一个块。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见错误现象：有人写
var s []int; s = append(s, 1)然后担心 panic ——不会，nil 是合法切片值 - 使用场景：构建动态集合（如遍历 map 收集 key）、函数返回可变长结果，都适合从 nil 开始 append
- 注意点：不能对 nil 切片做
s[0] = x或len(s)以外的索引操作，但append本身无此限制
为什么 append 后 len 没变但 cap 变了？
因为 append 只改变长度（len），容量（cap）只在扩容时被动更新。如果原切片还有空余容量，append 只增加 len，cap 保持不变。
- 典型误判：打印
len(s)和cap(s)发现 cap 比 len 大很多，以为“浪费内存”——其实这是预留空间，后续 append 可避免复制 - 调试技巧：用
fmt.Printf("%p %d/%d", &s[0], len(s), cap(s))观察底层数组地址是否变化，就能确认是否触发扩容 - 容易被忽略的地方：用
copy或append截取子切片时，新切片 cap 会继承原 cap 减去起始偏移，可能导致意外的底层数组泄漏（比如大数组只用几个元素，但整个底层数组无法 GC）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
