go 的内存剖析默认启用但采样率极低（memprofilerate=512kb），几乎无运行时开销；cpu 剖析则完全按需启动，不调用 pprof.startcpuprofile() 即零成本。因此，内存 profiling 并非真正“always on”，而是低开销、可动态关闭的默认可观测机制。
在 Go 运行时中，CPU 和内存 profiling 的启用机制截然不同，这也直接决定了它们的运行时开销特性：
CPU profiling 是严格按需的：必须显式调用 pprof.StartCPUProfile() 启动，且会启动一个后台 goroutine 定期采样调用栈。只要不调用该函数，就完全没有 CPU 开销，也不会分配额外资源。停止时需调用 pprof.StopCPUProfile()，否则可能引发 panic。
-
Memory profiling（堆剖析）则默认“轻量开启”：运行时全局变量 runtime.MemProfileRate 默认值为 512KB（即每分配约 512KB 堆内存触发一次采样）。这意味着：
- 它不是“always on”意义上的全量追踪（如 Java 的 -XX:+HeapDumpOnOutOfMemoryError 那样持续记录所有对象）；
- 而是一种低频、概率性采样机制，仅记录被采样到的堆分配调用栈；
- 其性能开销通常可忽略（实测对多数应用影响 < 1%），因此被设计为默认启用——便于在生产环境突发内存增长时，无需重启即可获取初步堆快照。
你可以通过以下方式控制内存剖析行为：
import "runtime"
func main() {
// 方式1：程序内动态关闭（需在 init 或 main 开头尽早设置）
runtime.MemProfileRate = 0 // 完全禁用堆采样
// 方式2：启动时通过环境变量（Go 1.5+）
// $ GODEBUG=memprofilerate=0 ./myapp
// 方式3：按需导出快照（仍需 MemProfileRate > 0 才有数据）
f, _ := os.Create("heap.pprof")
defer f.Close()
pprof.WriteHeapProfile(f) // 写入当前堆的采样快照
}⚠️ 注意事项：
- MemProfileRate = 0 禁用采样后，pprof.WriteHeapProfile() 将输出空文件（无堆栈信息）；
- 若设为 1，则每次 malloc 都采样——严重拖慢性能，仅限调试使用；
- CPU profiling 文件需用 go tool pprof 分析：go tool pprof cpu.pprof；堆文件同理：go tool pprof heap.pprof；
- 生产环境推荐结合命令行标志灵活控制，例如：
flag.BoolVar(&enableCPU, "cpuprofile", false, "enable CPU profiling")
flag.BoolVar(&enableHeap, "memprofile", false, "enable memory profiling at exit")
// ... 在 main 中
if enableCPU {
f, _ := os.Create("cpu.pprof")
pprof.StartCPUProfile(f)
defer pprof.StopCPUProfile()
}
if enableHeap {
defer func() {
f, _ := os.Create("heap.pprof")
pprof.WriteHeapProfile(f)
f.Close()
}()
}总结：Go 的内存 profiling 是一种默认启用、低开销、可配置关闭的观测基础设施，而非“always on”的重型监控。它平衡了诊断可用性与运行时成本，是 Go 生产就绪（production-ready）设计的重要体现。合理利用 MemProfileRate 和命令行开关，可在开发、测试与生产环境中实现按需、轻量、安全的性能洞察。
