Go 的 append 仅在 len(s) == cap(s) 时扩容并拷贝内存，否则直接写入原数组；扩容策略分段计算且对齐内存；必须接收返回值，因切片是值传递；共享底层数组可能导致静默bug。
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→ 下次扩容先算2048 + 2048/4 = 2560，再对齐到 8 字节边界 → 实际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) - 并发写同一个切片必须自己加锁——
append不是原子操作，竞态下可能数据覆盖或 panic - 从大缓冲区切出多个子切片做网络解析，其中一个
append触发扩容，其余子切片仍读旧内存，可能拿到脏数据
最常被忽略的点是：append 返回的新 header 是值，而底层数组是否迁移只取决于 len == cap 这一瞬时状态——它既不依赖历史增长节奏，也不受你“觉得该扩容了”的主观判断影响。
