预分配容量避免多次底层数组复制：append 超出 cap 时需申请新数组（1.25–2 倍）并拷贝旧数据，循环中开销显著；make([]T, 0, n) 一次性分配足够空间，更高效。

为什么 make([]T, 0, n) 比 append 累加更高效

因为预分配容量能避免多次底层数组复制。每次 append 超出当前 cap，运行时会申请新数组（通常是旧容量的 1.25–2 倍），再把旧数据拷贝过去——这在循环中反复发生时开销明显。

• 小切片（len ）：扩容策略是翻倍；大切片则按 1.25 倍增长，但仍可能触发 3–5 次复制
• 若已知最终长度（如读取文件行数、HTTP 响应条目数），直接用 make([]T, 0, expectedLen) 一次性配齐 cap
• 注意：make([]T, n) 会初始化前 n 个元素（填零值），而 make([]T, 0, n) 只预留空间，len=0，更符合“先攒数据再用”的场景

append 时传入切片而非单个元素能减少函数调用开销

Go 的 append 是内置函数，但语法糖背后仍有参数检查和边界判断。当批量追加时，把源数据组织成切片再整体 append，比逐个调用快且内存更友好。

• 错误写法：

  for _, v := range src {
      dst = append(dst, v)
  }

• 推荐写法：

  dst = append(dst, src...)

  （前提是 src 类型匹配，且你信任其长度）
• 若 src 是动态生成的（如从 map 遍历得来），先收集到临时切片再展开，比边遍历边 append 更少触发扩容

用 copy 替代多次 append 实现“零分配”拼接

当目标切片容量已足够（比如提前 make 过），直接用 copy 写入，完全绕过 append 的长度/容量管理逻辑，也没有新增堆分配。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 适用场景：已知总长度、分段处理、结果写入固定缓冲区（如序列化、IO 写入）
• 示例：

  buf := make([]byte, 0, totalSize)
  offset := 0
  for _, part := range parts {
      n := copy(buf[offset:], part)
      offset += n
  }

• 关键点：copy 不改变 len，所以需手动维护 offset；最终可用 buf[:offset] 得到有效数据

警惕 nil slice 和空 slice 在扩容行为上的差异

nil slice（值为 nil）和 len==0 && cap==0 的空切片，在首次 append 时都触发分配，但初始容量策略不同——这是容易被忽略的性能抖动点。

立即学习“go语言免费学习笔记（深入）”；

• var s []int（nil）：首次 append 分配容量为 1（不是 0）
• s := make([]int, 0)（空切片）：首次 append 也分配容量为 1
• 但 s := make([]int, 0, 100) 就明确设了容量，后续 100 次 append 都不扩容
• 反模式：var s []int; for i := 0; i → 至少 7 次底层数组复制（1→2→4→8→16→32→64→100）

实际项目里，真正影响 slice 性能的往往不是单次操作，而是循环中隐式扩容的累积效应。预估长度、善用 ... 展开、以及用 copy 控制写入位置，这三招覆盖了绝大多数优化场景。