面试官考察的是从真实代码识别性能问题的能力，如result += s会触发频繁GC；通过-go build -gcflags="-m -l"查看逃逸分析，重点关注“escapes to heap”和“does not escape”；pprof需先启用profiling接口，火焰图要下钻至第3–4层；strings.Builder适用于90%字符串拼接，比bytes.Buffer更轻量；sync.Pool适用于创建开销大、结构稳定的对象，但需检查Get()返回nil并兜底；性能优化本质是代码与边界的对话。
面试官不是在考你背了多少调优口诀，而是看你能不能从一段真实代码里闻出性能味儿——比如 result += s 这种写法，基本等于主动递上GC暂停时间的入场券。
怎么看逃逸分析结果
编译时加 -gcflags="-m -l" 是最直接的方式。重点盯住两句话：... escapes to heap 和 ... does not escape。前者说明变量被分配到堆，后者代表它大概率留在栈上。
- 常见逃逸点：返回局部变量地址（
return &x）、传入 goroutine、闭包捕获、赋值给 interface{} 或 map/slice 元素 - 注意：加
-l是为了禁用内联，否则编译器可能把函数内联后“掩盖”逃逸路径，导致误判 - 实际调试中，建议先用
go build -gcflags="-m -m" main.go看两层详细输出，比单-m更准
pprof 定位 CPU 热点的实操要点
别一上来就跑 go tool pprof，先确保程序开了 profiling 接口：
- HTTP 服务：导入
_ "net/http/pprof"，然后访问/debug/pprof/profile?seconds=30抓 30 秒 CPU 样本 - 非 HTTP 场景：用
pprof.StartCPUProfile+pprof.StopCPUProfile手动控制采样区间 - 火焰图里别只看顶层函数，要下钻到第 3–4 层——真正耗时的往往藏在
runtime.mallocgc或strings.Builder.WriteString这类基础调用里
strings.Builder 和 bytes.Buffer 怎么选
90% 的字符串拼接场景，用 strings.Builder 就够了。它比 bytes.Buffer 更轻量，因为不实现 io.Reader，也没有额外的 ReadFrom 方法开销。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须用
bytes.Buffer的情况：需要后续调用Buffer.Bytes()后再做二进制处理（比如加密、压缩），或要兼容已有接受io.Writer接口的函数 - 容易踩的坑：
Builder.String()返回的是新字符串，底层字节数组不会复用；如果拼完还要反复修改，不如直接用[]byte配合append - 性能差异在高频小拼接（如日志格式化）中非常明显：10 万次拼接，
Builder比+=快 8 倍以上，内存分配次数从 10 万次降到 1 次
sync.Pool 复用对象的边界在哪
sync.Pool 不是银弹。它适合生命周期短、创建开销大、且对象结构稳定的场景，比如 JSON 解析器、HTTP header map、临时切片。
- 别池化基础类型（
*int,string）或小结构体（struct{a,b int}），GC 回收它们比从 Pool 取还快 - Pool 中的对象可能被 GC 清理掉，所以每次
Get()后必须检查是否为 nil，并做好初始化兜底 - 高并发下 Pool 的本地缓存（per-P）能避免锁竞争，但若对象太大（>32KB），会绕过 Pool 直接走堆分配
真正难的不是记住 Builder 比 += 快，而是看到一段 make([]byte, 0, n) 时，能立刻反应过来：这里预分配是否合理？n 是常量还是来自不可信输入？如果 n 被恶意设成 GB 级，会不会直接 OOM？性能优化的终点，永远是代码与边界的对话。
