用go build -gcflags="-m -l"查看escapes to heap提示可判断变量是否逃逸到堆；常见逃逸点包括返回局部变量指针、闭包捕获循环变量、接口装箱（如log.Printf传int）等。
高频内存分配会直接推高 GC 频率、拉长 STW 时间、拖慢 P99 延迟——这不是“写法不够优雅”的问题，而是微服务上线后真实发生的性能退化根源。
怎么判断变量是不是逃逸到堆上了
Go 编译器自动决定变量分配位置，但一旦逃逸，就强制堆分配。不查就猜，等于在盲调。
- 用
go build -gcflags="-m -l"编译，重点找escapes to heap提示 - 常见逃逸点：
return &User{}、闭包捕获循环变量（for i := range xs { go func() { use(i) }() }）、传interface{}（比如log.Printf("id=%d", id)中的id会装箱） - 小结构体（≤ 32 字节）优先值传递：
process(User{ID: 123})比process(&User{ID: 123})更可能栈分配，也更轻量
sync.Pool 怎么用才不翻车
sync.Pool 不是缓存，是每个 P 私有的临时对象复用池，适合生命周期短、结构一致的对象（如 []byte、bytes.Buffer、HTTP 上下文）。
- Get 后必须重置：
buf.Reset()或buf = buf[:0]，否则残留数据可能引发 panic 或逻辑错误 - Put 前别留引用：归还前确保没把
buf塞进 map、全局 slice 或 goroutine 外部作用域，否则内存泄漏 + GC 扫描负担加重 - Get 可能返回
nil（GC 清理时）：需兜底，例如if buf == nil { buf = make([]byte, 0, 1024) } - 别用它存含 finalizer 或深层指针链的对象——Pool 无法安全管理其生命周期
预分配切片容量为什么比 append 更快
未指定容量的 make([]T, 0) 在首次 append 时分配底层数组；后续扩容会 malloc 新数组、拷贝旧数据、丢弃旧数组——这既是额外分配，也制造内存碎片。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 能预估数量就显式声明：
make([]int, 0, 1000)比make([]int, 0)少 8–10 次 realloc（按默认 1.25 倍增长策略） - 处理字符串行数时，用
strings.Count(s, "\n") + 1估算再预分配，比边读边append快 2–3 倍 -
make([]T, 0, N)只建 header，数组延迟分配；make([]T, N)立即分配 N 个元素空间，未使用部分仍占内存 - 过度预分配（如 cap=1MB）虽免扩容，但若只用 1KB，剩下 999KB 长期占着不释放，反而浪费
哪些看似省事的操作其实在偷偷 malloc
很多写法表面简洁，背后却在高频路径上反复堆分配：
-
fmt.Sprintf和fmt.Println：对大字符串或结构体调用时极易逃逸，改用strings.Builder或预分配bytes.Buffer - 循环中
string(b)或[]byte(s)：每次转换都触发一次堆分配，必要时用unsafe.String/unsafe.Slice零拷贝（需确认生命周期安全） - 频繁创建小结构体实例（如
type Req struct{ ID int; Path string }），又没复用机制——直接上sync.Pool或客户端传参复用 - golang-lru 的
simplelru.LRU默认每次Add都 newEntry，高频写场景下建议对象池复用或改用预分配容量 + 自定义onEvicted回调清理
最易被忽略的点：GC 压力不是单点问题，而是多个小逃逸、多次未重置的 Pool 对象、几处未预估的切片扩容叠加出来的。优化得从 pprof + trace 定位真实热点开始，而不是凭经验改某一行。
