sync.Pool适用于短生命周期、结构固定的临时对象复用，需手动重置状态、清空敏感数据，New函数仅在Get返回nil时调用且不保证唯一性，不适合长生命周期或大小不稳定的对象。
最直接有效的办法是：让对象不进堆——要么留在栈上，要么复用已分配的堆内存。高频分配不是写法问题，而是 P99 延迟和 GC STW 拉长的硬伤。
怎么用 sync.Pool 复用对象但不 panic
sync.Pool 不是缓存，是每个 P（逻辑处理器）私有的无锁复用池，只适合生命周期短、结构一致的临时对象，比如 []byte、*bytes.Buffer、strings.Builder。
- 每次
Get()后必须重置状态：buf.Reset()或buf = buf[:0]；否则下次拿到的是脏数据，strings.Builder甚至会因内部指针越界直接 panic -
Get()返回nil是合法行为，必须兜底：buf := bufPool.Get().([]byte) if buf == nil { buf = make([]byte, 0, 1024) } - 别把 pool 对象塞进全局
map或slice：等于手动制造内存泄漏，还加重 GC 扫描负担 - 池中对象随时可能被 GC 清理，不能依赖其存活；含大内存引用（如内部持有 1MB
[]byte）时，等于隐式内存泄漏
为什么 make([]T, 0, N) 比 make([]T, N) 更省
区别不在“分配多少”，而在“是否触发后续扩容”。make([]int, 10) 立即分配 10 个元素空间，哪怕只写前 3 个，后 7 个仍占着内存；而 make([]int, 0, 10) 底层只预分配 cap=10 的数组，len=0，append 直接复用，避免中间态浪费。
- 未预分配的
var s []int循环 100 次，按默认 1.25 倍增长策略可能 realloc 8–10 次 - 字符串分割可先用
strings.Count(s, "\n") + 1估算行数再预分配，比边读边append快 2–3 倍 - 过度预分配风险明显：
cap=1MB却只用 1KB，剩下 999KB 长期占着不释放，反而拖慢 GC 扫描
怎么确认变量真正在栈上，而不是“以为在栈上”
Go 编译器自动做逃逸分析，但“取地址”“传 interface{}”“闭包捕获”“返回指针”都会强制堆分配。这不是 bug，是设计行为——但高频逃逸就是性能瓶颈。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
go build -gcflags="-m -l"查看真实逃逸结果，重点关注escapes to heap提示 - 典型强逃逸点：
return &User{}、fmt.Printf("%s", s)（大字符串）、for i := range xs { go func() { use(i) }() }（i逃逸供所有 goroutine 共享） - 小结构体（≤32 字节）优先值传递：
process(User{ID: 123})比process(&User{ID: 123})更轻量，且大概率栈分配 - 函数参数是
interface{}时，实参值通常逃逸（哪怕是个int）；日志场景改用lo等零分配日志库更稳妥
哪些标准库调用在暗中疯狂分配
高频分配大户往往藏在“方便”背后，容易被忽略：
-
fmt.Sprintf：每次调用至少分配一个[]byte和一个string，底层虽用sync.Pool缓冲但不保证复用 -
strings.ReplaceAll：内部调用strings.Builder，但每次都会新建实例（其buf字段是[]byte，默认初始容量 0） -
encoding/json.Marshal：结构体字段多、嵌套深时，临时map、slice、string大量生成；尤其字段名含大小写混用或tag不规范时，反射路径更长、分配更多 -
http.Request.URL.Query()：返回新url.Values（本质是map[string][]string），每次调用都new map
替代方案要具体到操作：用 strconv.AppendInt 替代 strconv.Itoa，前者接受 []byte 并追加，后者总返回新 string；解析 JSON 尽量直接用字节切片输入，避免先转成 string。
