append只在len(s) == cap(s)时真正触发扩容；小容量(<1024)翻倍，大容量(≥1024)按1.25倍向上取整并8字节对齐，空slice首次append分配1个元素空间。
预分配容量是唯一能彻底避免大体积切片追加时反复扩容的手段；其他所有“技巧”都只是缓解，不是根治。
什么时候 append 才真正触发扩容？
只在 len(s) == cap(s) 的瞬间触发，不是每次 append 都分配新内存。很多人看到 cap(s) 还剩 200 就以为安全，结果下一次 append 后 &s[0] 地址变了——那说明上一轮已把 len 拉到等于 cap，这次才是真正的扩容点。
常见错误现象：
- 用
make([]int, 0)初始化后循环追加 10 万次，至少触发 17 轮扩容（0→1→2→4→…→131072），累计拷贝超 2MB 数据 - 误以为
append(s, x)是原子操作，其实它可能包含：检查容量 → 分配新数组 → 复制旧数据 → 写入新元素 → 更新头结构
如何用 make 预设容量才真正有效？
必须用三参数形式：make([]T, 0, expectedCap)。两参数 make([]T, n) 会把 len 和 cap 都设为 n，后续只要追加一个元素就立刻扩容。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 若知道确切数量（如读取固定行数的文件），直接设
cap = n - 若只有上限（如单次最多处理 65536 条日志），按上限设，宁可略浪费内存，也别让 runtime 自己猜
- 若完全未知但有典型规模（如平均 1000 条/批次），设
cap = 2048—— 它比 1024 更容易对齐，且跳过小容量翻倍阶段
为什么不能依赖扩容策略做性能估算？
Go 的扩容规则藏在 src/runtime/slice.go 里，不是简单乘 2 或 1.25：小于 1024 翻倍，≥1024 时按 old + old/4 向上取整到 8 字节对齐。例如 cap=2048 扩容后是 2560，cap=3000 则变成 3760。
关键影响：
- 相同初始
cap、不同追加节奏（一次追加 100 个 vs 每次追加 1 个），最终底层数组地址可能完全不同 - 扩容后新
cap总是 8 字节对齐，这是为了内存分配器效率，不是随意设计 - 不要用
&s[0] == &t[0]判断是否共享底层数组，地址比较不可靠
复用切片时最容易被忽略的坑
s = s[:0] 看似清空，但前提是没人还在引用原底层数组。一旦上游或 goroutine 中还存着 s1 := s[5:10] 这类截取切片，s[:0] 就可能意外覆盖别人的数据。
安全复用的前提：
- 确认该切片生命周期可控，无外部引用
- 若需跨 goroutine 复用，优先走
sync.Pool，而不是全局变量传参 - 函数返回切片前，务必用三参数截取：
t := s[i:j:k]，显式收紧cap，确保后续append(t, x)必然扩容，不污染原数组
最隐蔽的问题：你优化了扩容次数，却没意识到底层数组因截取而长期无法 GC —— 那块内存可能比切片本身大十倍。
