go的append扩容非简单翻倍：cap
append 扩容不是每次翻倍，而是有明确阈值规则
Go 的 append 在底层数组容量不足时会触发扩容，但不是简单地「×2」。实际策略是：当原容量 cap 小于 1024 时，新容量 = cap * 2；超过 1024 后，每次只增加约 25%（即 cap + cap/4）。这个设计是为了平衡内存浪费和重分配次数。
常见错误现象：append 后再取 &slice[0] 地址突变，导致意外指针失效；或循环中反复 append 却没预估容量，引发多次拷贝拖慢性能。
- 使用场景：构建动态列表、解析不定长数据流、拼接日志条目
- 如果已知最终长度（比如读取 5000 行文件），优先用
make([]T, 0, 5000)预分配 - 避免在 tight loop 中无节制
append，尤其当元素是大结构体时，拷贝开销明显
底层数组共享导致的“隐式修改”问题
append 返回的新切片，只要没触发扩容，就和原切片共用同一底层数组。这意味着：修改新切片某元素，可能意外改到旧切片里对应位置的数据。
典型例子：传入一个切片给函数做 append 并返回，调用方后续继续操作原变量，结果发现值变了。
立即学习“go语言免费学习笔记（深入）”；
- 判断是否扩容：比较
len(s)和cap(s)，若len == cap，下一次append必定新建底层数组 - 安全做法：需要隔离修改时，显式复制，如
newSlice := append([]T(nil), oldSlice...) - 注意
append(s[:0], ...)这种写法仍复用原底层数组，不是清空+隔离
nil 切片也能 append，但行为容易误判
nil 切片的 len 和 cap 都是 0，但它能直接传给 append —— 第一次调用会自动分配底层数组。这点常被当成“安全默认值”滥用。
问题在于：append(nil, x) 返回的是新分配的切片，而 append(s, x)（s 非 nil）可能复用原数组。混合使用时，代码逻辑对底层数组生命周期的假设会出错。
- 不要依赖
nil切片的“自动初始化”来简化接口，明确区分“未初始化”和“空但已分配” - 若函数参数允许
nil，内部应统一用make([]T, 0)初始化后再append，避免行为不一致 - 调试时可用
fmt.Printf("%p", &s[0])看底层数组地址是否变化
多参数 append 和 ... 展开的边界情况
append 支持多个元素或一个切片加 ...，但两者不能混用（语法错误），且 ... 只能出现在最后一个参数。
常见错误：把 append(dst, src...) 写成 append(dst, src)（漏掉 ...），导致编译失败或传入切片本身而非其元素。
-
append(a, b...)要求a和b是同一类型切片；若b是数组，需先转为切片（如b[:]...） - 传入空切片
[]int{}加...不会 panic，但也不追加任何元素，行为符合直觉 - 性能上，
append(dst, src...)比循环调用append(dst, src[i])更快，因为底层可一次性拷贝
扩容逻辑和底层数组共享，是 append 最容易被忽略的两个复杂点——它们不写在文档最前面，却决定着程序是否在某个数据规模下突然变慢或行为异常。
