切片扩容不是简单翻倍，而是分段策略：cap < 1024 时翻倍，≥1024 时按1.25倍增长并8字节对齐；触发条件是 append 后 len > cap，扩容后底层数组地址变更，旧子切片失效，预分配 make([]T, 0, n) 可彻底避免扩容开销。
切片扩容不是简单翻倍
Go 的 append 在底层数组容量不足时会触发扩容，但规则比“×2”更精细：小于 1024 字节时按 2 倍增长；超过后按 1.25 倍（即 +25%）增长。这个阈值是按元素大小 × 长度算的，不是单纯看 len 或 cap。
容易踩的坑是误以为扩容总发生于 len == cap 时——其实只要 append 后超出当前 cap 就会触发，且新底层数组地址必然变化（原 slice 变量不感知），导致后续对旧 slice 的写入不反映在新 slice 上。
- 若元素类型是
[]int64（8 字节），长度 120 → 容量约 120×8 = 960 字节，仍走 2 倍扩容 - 长度 129 → 129×8 = 1032 > 1024，下次扩容变成 129 → 161（向上取整到 1.25×129 ≈ 161.25 → 162？实际是 161，Go 内部用位运算和常量表优化）
- 扩容后旧数据被
memmove复制，不是原地 realloc —— 这意味着大 slice 扩容有明显延迟，尤其在高频append场景下
如何预估容量避免频繁扩容
如果已知最终长度（比如解析固定行数的 CSV），直接用 make([]T, 0, expectedCap) 初始化 slice，比反复 append 快 3–5 倍（实测小 slice 差异不大，但 >10k 元素时 GC 压力和分配次数显著下降）。
注意：make([]T, n, m) 中 n 是 len，m 是 cap；若填 make([]T, 0, 0)，底层数组可能为 nil，首次 append 仍要分配 —— 不等于“零成本”。
立即学习“go语言免费学习笔记（深入）”；
- 读文件逐行
append时，可先stat文件行数，或用缓冲区预估（如每行平均 80 字节，文件 8MB → 约 10w 行 →make([]string, 0, 100000)） - HTTP body 解析 JSON 数组，可用
json.Decoder配合预分配 slice，避免json.Unmarshal内部反复扩容 - 不要依赖
cap精确等于期望值：Go 可能按内存对齐向上取整（如cap为 127 的[]int实际分配 128 个 slot）
slice 扩容后指针失效的真实影响
扩容产生新底层数组，所有基于旧底层数组的 slice（包括子切片）都会与新 slice 脱离。这不是 bug，是设计使然 —— Go 不保证 slice 间共享关系在扩容后延续。
典型错误场景：传入函数的 slice 在函数内被 append，调用方未接收返回值，就以为原 slice 已更新。
-
func add(s []int) { s = append(s, 1) }→ 调用后原 slice 不变，因为s是副本，且扩容后指向新地址 - 正确做法是
func add(s []int) []int { return append(s, 1) }，显式返回新 slice - 子切片如
s2 := s[1:3]，即使s未扩容，只要s后续扩容，s2仍指向旧内存，不会自动迁移
对比其他语言的动态数组扩容策略
Go 的扩容策略介于 Python（严格 12.5% 增长，即 1.125×）和 Rust（默认 2×，但 Vec::with_capacity 更常用）之间，偏保守。它不追求理论最优，而是平衡内存碎片与重分配频率。
真正关键差异在于：Go slice 是值类型，传递开销小但语义上“无隐式共享延续”；而 Python list / Java ArrayList 是引用类型，扩容对所有别名可见（但代价是每次 append 都要检查容量并可能锁）。
- Rust 的
Vec::push也用 2×，但允许自定义 allocator；Go 没有暴露 allocator 接口，无法替换 - JavaScript 的 Array.push 在 V8 中用类似策略，但引擎会根据使用模式启发式调整（如 detect “dense array” 后改用连续内存）
- 如果你从 Python 转 Go，最容易忽略的是：没有
.extend()的就地语义 ——append(dst, src...)返回新 slice，dst 不变
扩容机制本身不复杂，难的是在真实业务中判断“何时预分配”“是否值得预估”“哪些 slice 生命周期必须由调用方管理”。这些决策点往往藏在日志吞吐、API 响应链、配置加载等非核心路径里，一不留神就成了性能毛刺源。
