不是必须，但最常用方式是启用net/http/pprof默认路由；它仅注册handler，需手动调用http.ListenAndServe暴露端口；本地调试推荐runtime/pprof直写文件，避免端口冲突或网络依赖。
pprof 采集 CPU 和内存数据时，必须手动启动 HTTP 服务吗？
不是必须，但最常用的方式是启用 net/http/pprof 的默认路由。它本身不启动服务，只是注册 handler；你需要自己调用 http.ListenAndServe 才能暴露端口。本地调试时更推荐用 runtime/pprof 直接写文件，避免端口冲突或网络依赖。
常见错误：只导入 _ "net/http/pprof" 却没启动 HTTP server，导致 curl http://localhost:6060/debug/pprof/ 返回 404。
- 线上服务建议用 HTTP 方式，配合
pprof -http工具实时抓取 - 单测或 CLI 工具中，直接用
pprof.StartCPUProfile+WriteHeapProfile - 注意：CPU profile 默认采样频率是 100Hz，对高频短任务可能漏掉关键热点，可传入
runtime.PprofCPUProfileRate调整
go test -bench 对比结果里，ns/op 越小越好，那 MB/s 是越大越好吗？
是的，但前提是基准一致。MB/s 表示单位时间处理的数据量，只在相同输入结构（如都用 []byte）、相同操作类型（如都做 JSON marshal）下才有横向可比性。如果两个 benchmark 一个读磁盘一个读内存，MB/s 数值完全不能反映真实性能差异。
容易被忽略的点：
立即学习“go语言免费学习笔记（深入）”；
-
-benchmem必须显式加，否则不会输出内存分配统计（allocs/op、B/op） - benchmark 函数名必须以
Benchmark开头，且接收*testing.B - 循环体里别用
b.N做条件判断以外的事，比如初始化放错位置会导致结果偏差 - Go 1.21+ 默认启用
benchtime自适应，若想固定运行时长（如 3 秒），加-benchtime=3s
用 pprof 分析火焰图时，为什么 top 显示的函数和代码行对不上？
通常是符号信息丢失或内联优化导致。Go 编译默认开启内联（-gcflags="-l" 可禁用），编译器把小函数直接展开进调用方，pprof 采样到的是汇编地址，无法还原原始行号。
实操建议：
- 生成二进制时加
-gcflags="all=-N -l"关闭优化，确保符号完整 - 用
go tool pprof -http=:8080 binary_name cpu.pprof启动交互界面，比命令行top更准 - 如果看到大量
runtime.mcall或runtime.gopark占比高，大概率是 Goroutine 阻塞或 channel 等待，不是 CPU 瓶颈 - 检查是否误将
log.Printf、fmt.Println放在 hot path 上——它们会触发锁和内存分配，显著拖慢 profile
pprof heap profile 显示大量 runtime.mallocgc，但实际业务代码没显式 new，怎么定位？
这是 Go 内存分配的正常入口，不代表你写了 new()。真正要查的是它的调用栈上层——谁触发了这次分配。常见元凶包括：
- 字符串拼接：
s := a + b + c在非 const 场景下每次生成新字符串 - 切片扩容：
append(s, x)当底层数组不足时触发 realloc - 接口赋值：
var i interface{} = obj会拷贝值并分配接口头 - 闭包捕获变量：如果捕获了大结构体或 slice，可能隐式逃逸到堆
验证方式：用 go run -gcflags="-m -l" main.go 查看逃逸分析，重点关注 ... escapes to heap 提示。
func process(data []int) []int {
result := make([]int, 0, len(data)) // 这里预分配可避免多次 mallocgc
for _, v := range data {
result = append(result, v*2) // 如果没预分配，每次 append 可能 realloc
}
return result
}
复杂点在于，同一行代码在不同上下文中逃逸行为可能不同。profile 只告诉你“哪里分配多”，逃逸分析才告诉你“为什么分配”。两者得一起看。
