make([]int, 0, 10) 更省内存，因其底层数组预分配但 len=0，append 可复用空间；而 make([]int, 10) 立即分配 10 个元素，未使用部分仍占内存。
为什么 make([]int, 0, 10) 比 make([]int, 10) 更省内存？
关键不在“分配多少”，而在“后续是否触发扩容”。make([]int, 10) 立即分配 10 个元素空间，但若你只写入前 3 个，后 7 个仍是已分配、未使用的内存；而 make([]int, 0, 10) 底层只预分配底层数组（cap=10），len=0，append 时直接复用，避免中间态浪费。
常见误判：认为 cap 预分配只是“为未来扩容准备”，其实它直接决定首次底层数组的 malloc 大小。Go 的 slice 扩容策略（2 倍或 1.25 倍）在 cap 不足时会 malloc 新数组 + copy，这是高频分配源。
- 对已知上限的场景（如解析固定字段 JSON、读取定长 buffer），优先用
make(T, 0, N) - 避免无脑
append到空 slice：如果循环中累计 100 条数据，且能预估总数，就用make([]T, 0, 100) - 注意：cap 过大也会浪费，比如预估 1000 但实际只存 5 条，那 995 个 int 就是纯占内存
如何定位代码里偷偷分配内存的 interface{}？
Go 中隐式装箱是内存分配黑盒：把一个栈上变量（如 int）传给接收 interface{} 的函数（如 fmt.Printf、map[string]interface{}、json.Marshal），会触发堆上分配。这不是 bug，是语言设计，但高频调用下很伤。
典型高危场景：
立即学习“go语言免费学习笔记（深入）”；
-
log.Printf("id=%d", id)→ 改用log.Printf("id=%d", int64(id))避免 int→interface{} 装箱（尤其 id 是 int32/int64 混用时） -
m["ts"] = time.Now().UnixMilli()→ 若 m 是map[string]interface{}，每次赋值都分配；改用 struct 或专用 map 类型 -
json.Marshal(map[string]interface{}{"code": 200, "msg": "ok"})→ 替换为预定义 struct +json.Marshal(&MyResp{...})
验证方法：用 go tool trace 查看 heap profile，或跑基准测试对比 BenchmarkAllocsPerOp 数值变化。
sync.Pool 什么时候用反而更耗内存？
sync.Pool 不是银弹。它适合“创建代价高 + 生命周期短 + 对象可复用”的场景，比如 *bytes.Buffer、*sync.WaitGroup、临时切片。但滥用会导致三类问题：
- 对象长期滞留 pool 中不被 GC：pool 只在 GC 前清理，若对象引用了大内存（如内部持有 1MB []byte），且很少触发 GC，等于内存泄漏
- 误存不可复用对象：比如带状态的 struct，从 pool.Get() 拿出后未重置字段，下次使用时行为异常，调试困难
- 小对象得不偿失：比如只存几个 int 字段的 struct，new 一次成本远低于 pool 的原子操作和哈希查找开销
实操建议：
- 只 pool 明确观察到高频 new 的对象（pprof allocs_inuse_objects 看 top 函数）
- Get 后必须 reset（如
b.Reset()for Buffer），Put 前确保不再引用 - 避免在 HTTP handler 中无节制 Put：连接多时 pool 会膨胀，考虑搭配限流或 size cap
字符串拼接选 strings.Builder 还是 bytes.Buffer？
两者底层都是预分配 + grow，但语义和默认行为不同：strings.Builder 是 Go 1.10+ 专为 string 构建优化的，零拷贝转 string；bytes.Buffer 更通用，但 Buffer.String() 会额外 copy 一次底层字节。
性能差异在高频小拼接中明显（比如日志格式化、模板渲染）：
- 确定最终结果是 string → 用
strings.Builder，调用builder.String()零分配 - 中间要写入二进制/需
WriteTo(io.Writer)→ 用bytes.Buffer - 别用
+=拼接：每次都会 new 新 string，时间复杂度 O(n²)，且无法控制底层数组复用
一个易忽略点：strings.Builder 的 zero value 是有效状态，无需初始化；但若曾调用过 Reset()，再用前需确认没残留旧数据 —— 它不自动清空已写内容，只重置 len。
