正确预分配切片容量应使用 make([]T, 0, cap)，而非 make([]T, cap)，前者仅分配底层数组、len=0、cap=cap，避免冗余初始化和过早扩容。
预分配容量用 make([]T, 0, cap)，不是 make([]T, cap)
预分配切片容量的核心动作，就是让底层数组一次到位，后续 append 不触发 realloc。但很多人写成 make([]int, 1000)，这其实分配了 1000 个已初始化的元素——你只打算存 500 个？那白占一半内存；更糟的是，它还可能掩盖扩容问题：因为 len == cap，第一次 append 就得扩容。
正确姿势是：make([]int, 0, 1000)。它只申请底层数组（1000 个 int 空间），len = 0，cap = 1000，所有 append 都复用这块内存，直到第 1001 次才扩容。
-
make([]byte, 0, 4096)常用于读 buffer，比make([]byte, 4096)少一次初始化开销，也避免未用空间长期驻留 - 处理 JSON 数组字段时，可用
json.RawMessage先解析长度，再按字段数预分配目标切片 - 从文件逐行读取？先用
strings.Count(content, "\n") + 1估算行数，再make([]string, 0, lineCount)
预估不准时，宁可略大，别吝啬那点内存
扩容代价远高于“多分一点”。Go 的扩容策略是：小于 1024 时翻倍，超过后每次只加 25%。这意味着从空切片追加 10 万个 int，会经历约 17 次 malloc + copy；而 make([]int, 0, 100000) 是零扩容。
但别走极端——预设 cap = 1<em>1024</em>1024 却只存 3 条数据，就是纯浪费。合理做法是：
立即学习“go语言免费学习笔记（深入）”；
- 有明确上限（如协议头固定 16 字段）→ 直接设
cap = 16 - 常见规模在 10–200 之间 → 用
cap = 256，覆盖 99% 场景，成本可控 - 完全未知但高频调用（如日志拼接）→ 放进
sync.Pool，按 size 分池（smallBufPool/largeBufPool），不混用
复用切片别只靠 s = s[:0]，小心“假清空”
s = s[:0] 确实快，但它只是把长度归零，底层数组还挂着。如果这个切片含指针字段（比如 []*User），旧指针不清理，GC 就不敢回收对应对象——表面空了，内存却卡死。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
安全复用要分情况：
- 纯值类型（
[]int,[]byte）→s = s[:0]足够，无需额外操作 - 含指针或 map/slice 字段的结构体切片 → 必须遍历置零：
for i := range s { s[i] = MyStruct{} } - 跨 goroutine 或长生命周期复用 → 优先走
sync.Pool，并确保Put前已Reset（如bytes.Buffer.Reset()）
别在循环里无脑 append 到空切片
这是最典型的性能陷阱。现象是：pprof 显示大量 runtime.makeslice 和 runtime.growslice，GC 频次飙升，程序越跑越慢。
错误写法：
var result []string
for _, item := range items {
result = append(result, process(item))
}改进关键不在“怎么 append”，而在“怎么初始化”。只要能估算总量（哪怕粗略），就该提前算好：
- 已知
len(items) == N→result := make([]string, 0, N) - 每个
item可能产出 0–3 个字符串 → 按N * 3预估，比默认策略省至少 5 次扩容 - 实在无法估算 → 改用索引赋值：
result := make([]string, len(items)); for i := range items { result[i] = process(items[i]) }，彻底绕过append逻辑
真正难的不是记住语法，而是每次写 append 前，下意识问一句：我到底知道要塞多少个？
