append触发扩容的准确条件是len(slice) == cap(slice)，此时才分配新内存并复制数据；否则直接写入底层数组末尾，不扩容。
append 触发扩容的准确条件是什么
不是“一加就扩”，而是 len(slice) == cap(slice) 时才真正扩容。只要还有空余容量，append 就直接写入底层数组末尾，不分配新内存、不复制数据——这是高效的关键。
- 初始
var s []int：len=0，cap=0，第一次append(s, 1)必须分配，cap 变为 1 -
s := make([]int, 2, 4)：len=2，cap=4，还能无成本追加 2 个元素 - 若
cap是 0（如空切片），首次扩容后 cap 直接设为 1，不是翻倍
扩容倍数到底是 2 倍还是 1.25 倍
Go 的扩容策略分段生效，不是固定倍数，更不是“每次翻倍”——这是最常被误解的一点。
- 当前
cap ：新 cap =old cap * 2（例如 512 → 1024） - 当前
cap >= 1024：新 cap =old cap + old cap/4（即 ≈ 1.25×，例如 1024 → 1280） - 实际分配值还会向上对齐到内存边界（如 8 字节对齐），所以
cap偶尔会略大于理论值 - 一次
append添加多个元素时，Go 会先按需估算最小足够容量，再套用上述策略，可能跳过中间档位（例如从 cap=2 直接扩到 4 来容纳 3 个新元素）
扩容后旧切片还安全吗
不安全。一旦发生扩容，append 返回的是一个**全新底层数组**上的新切片，原切片仍指向旧数组——它们彻底断开共享关系。
- 这意味着：修改新切片不会影响旧切片，反之亦然；但如果你把旧切片当“备份”用，它不会反映新数据
- 典型坑：
s1 := []int{1,2}; s2 := s1; s1 = append(s1, 3)→ 此时s1和s2指向不同底层数组，s2仍是[1 2] - 引用类型（如
[]string、*struct{}）元素本身不被深拷贝，只是指针复制；扩容只影响切片结构体的ptr字段，不影响元素内容
怎么避免踩坑：预分配和显式控制
靠自动扩容省事，但高频或大数据量场景下，性能损耗和行为不确定性会暴露出来。
立即学习“go语言免费学习笔记（深入）”；
- 知道最终长度？用
make([]T, 0, expectedCap)预分配，比如要存 1000 条日志，直接make([]Log, 0, 1000) - 不确定长度但有上限？预分配上限值，比反复 realloc + copy 更快更 predictable
- 需要保留旧切片引用？别依赖
append返回值，自己用copy或新建切片控制所有权 - 调试时查真实地址：用
fmt.Printf("%p", s)看ptr是否变化，比猜更可靠
扩容看似透明，但它在指针、内存、GC 和并发安全之间划了一条隐性边界线——这条线不在文档里高亮，但在你看到数据没更新、内存暴涨、或 goroutine 间切片行为不一致时，它就在那里。
