append触发扩容时一定不复用原底层数组，仅当len==cap时才扩容，新切片指向全新数组，旧变量仍指向原数组，二者引用关系彻底断开。
append 触发扩容时，不一定复制数据，但一定不复用原底层数组
Go 切片的扩容不是“每次 append 都 realloc”，而是严格按需触发：只有当 len(s) == cap(s) 时才真正扩容。此时旧切片变量仍指向原数组，新切片（append 返回值）指向全新底层数组——二者彻底断开引用关系。这是绝大多数意外数据不一致问题的根源。
常见错误现象：
s := []int{1,2,3}; t := s; s = append(s, 4)
之后t仍是[1 2 3]，s是[1 2 3 4]，且修改s[0]不会影响t[0]容量刚好卡在临界点时行为易误判：
s := make([]int, 5, 5)→len==cap==5，追加第 6 个元素必扩容s := make([]int, 5, 6)→len==5, cap==6，追加 1 次不扩容，len变为 6 后才触发扩容后原变量未失效，但已与新切片无关：
不要写s := append(s, x); doSomethingWith(s); doSomethingWith(oldS)，oldS是旧数组快照，不是“旧状态”
容量小于 1024 时 append 扩容翻倍，但不是简单 ×2
Go 运行时对小容量切片（cap < 1024）采用倍增策略，但实际新容量会向上取整到内存对齐边界（通常是 8 字节对齐），所以结果未必是精确的 2×。
立即学习“go语言免费学习笔记（深入）”；
示例验证：
s := make([]int, 0, 7)→cap == 7s = append(s, make([]int, 10)...)（追加 10 个）→ 触发扩容
新容量不是 14，而是 16（7×2=14，向上对齐到 16）关键影响：
预分配时若按理论值算（如make([]int, 0, 1000)），实际分配可能略大于 1000（如 1024），但比多次小步扩容更省
若目标是精确控制内存块大小（如对接 C 接口、避免 cache line 冲突），不能依赖“翻倍”等于“×2”
make([]T, len, cap) 中 cap 参数决定是否提前规避扩容
cap 是预分配的底层数组长度，它不改变切片当前可读写的范围（由 len 控制），只预留空间。只要 len < cap，后续 append 就不会触发扩容。
使用场景：
已知最终元素数量（如解析 HTTP body 的 JSON 数组、批量读取数据库记录）
循环中固定次数追加（for i := 0; i < N; i++ { s = append(s, f(i)) }）容易踩的坑：
make([]int, 0, 1000)✅ 零长度、千容量，安全追加 1000 次make([]int, 1000)❌ 等价于make([]int, 1000, 1000)，浪费前 1000 个零值初始化s := []int{}; for i := 0; i < 1000; i++ { s = append(s, i) }→ 约 10 次扩容（2→4→8→…→1024），含多次内存拷贝
大容量切片（≥1024）扩容增长 25%，但增量非线性
当 cap >= 1024，Go 改用 cap += cap / 4（即 ×1.25）策略，目的是减缓指数级膨胀，同时避免频繁小步 realloc。
实际表现：
cap == 1024→ 新cap == 1280（1024 + 256）cap == 2048→ 新cap == 2560（2048 + 512）
但最终值仍会上调至最近的对齐数（如 1280 对齐后仍是 1280，2560 可能变成 2560 或 2568）性能提示：
单次扩容成本随容量增大而升高（memcpy 量变大），所以预分配对大切片收益更高
如果业务中切片常达数万元素，make([]T, 0, expectedSize)几乎是必须项，否则 GC 压力和延迟抖动明显
真实项目里最常被忽略的，不是“怎么扩容”，而是“谁还持有旧底层数组指针”——尤其在函数传参、结构体字段赋值、goroutine 间传递时，一个没注意的 append 就让两个变量悄然分道扬镳。
