Go 的 append 仅在 len(s) == cap(s) 时扩容并拷贝，否则零分配；返回新切片 header，必须接收返回值；共享底层数组是隐式风险源。
Go 的 append 不是“每次调用都扩容”，它只在 len(s) == cap(s) 时才真正分配新底层数组——这是你判断是否发生内存拷贝的唯一可靠依据。
扩容触发条件：只看 len 和 cap 是否相等
很多人误以为“容量快满了就会扩容”，其实 Go 完全不关心“还剩多少余量”，只检查一个硬条件：len(s) == cap(s)。只要不相等，append 就直接往原底层数组末尾写，零分配、零拷贝。
- 例如
s := make([]int, 2, 10)，此时len=2、cap=10，还能安全append8 次，都不扩容 - 但若
s := data[100:100]（从大数组切出的空切片），cap可能只有 50，第一次append就可能触发扩容 - 调试时别只打
len，加一句fmt.Printf("remaining: %d", cap(s)-len(s))才能看出真实余量
扩容后容量怎么算：分段策略 + 内存对齐
Go 不承诺精确容量值，但实现上遵循稳定分段规则：小于 1024 时翻倍，≥1024 后按 1.25 倍增长，再向上对齐到内存边界（如 int 切片对齐到 8 字节）。
-
cap = 512→ 下次扩容cap = 1024 -
cap = 2048→ 下次扩容cap = 2560（2048 + 2048/4），再对齐到 2568B → 实际cap = 321（2568 ÷ 8） - 一次追加大量元素（如
append(s, bigSlice...)），Go 会跳过倍增逻辑，直接按需分配 ≥ 总长度的最小合法容量 - 别手动模拟扩容公式——实测自定义预分配（如每次 +20）比 Go 原生慢 5–10 倍，且极易出错
必须显式接收返回值：不是语法糖，是值传递本质
append 返回的是一个全新的切片 header（指针 + len + cap），原变量完全不受影响。忽略返回值等于没操作，编译器会警告 "result of append not used"。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
append(s, x)；正确写法：s = append(s, x)或s = append(s, 1, 2, 3) - 函数内想让调用方看到变化，必须返回：
func add(s []int, x int) []int { return append(s, x) } - 传参也是 header 副本：函数里
append不会影响调用方的s，但s[i] = y会影响——因为指针仍指向同一底层数组 - nil 切片（
var s []int）能直接append，首次会自动分配，cap从 0 → 1，不是翻倍
共享底层数组是最隐蔽的坑
只要没扩容，append 返回的新切片和原切片就共用底层数组。这省拷贝，但也导致修改相互可见、指针悬垂、map value 污染等静默问题。
- 典型现象：
s1 := []int{1,2}; s2 := append(s1, 3); s2[0] = 99→fmt.Println(s1)输出[99 2] - 需要隔离时，别用
s[:0]（仍复用底层数组），安全做法是：newS := append([]int(nil), s...) - 存进 map 后再
append？更危险——map value 是副本，但若未扩容，仍指向原数组，后续修改可能污染其他 key - 并发写同一个切片？必须自己加锁——
append赋值非原子，底层写入位置可能重叠，引发 panic 或数据覆盖
最复杂的地方不在扩容公式，而在于你永远无法静态判断某次 append 是否会悄悄换掉底层数组。只要涉及指针、map 存储、跨 goroutine 共享，就必须主动掐断共享链。
