recover无法捕获panic的根本原因是它仅在defer函数内且panic正在传播时有效；若panic离开当前goroutine栈帧（如子goroutine中panic或主goroutine已退出），recover即失效，此时pprof是唯一回溯手段。
recover 无法捕获 panic 的根本原因
Go 的 recover 只能在 defer 函数中、且 panic 正在传播时调用才有效。一旦 panic 离开当前 goroutine 的栈帧（比如在子 goroutine 中 panic，或主 goroutine 已经退出），recover 就完全失效——这时 pprof 是你唯一能回溯现场的手段。
常见误用：在非 defer 函数里调用 recover()，或试图在 http handler 外层包一层 recover 却没加 defer，结果 panic 依旧崩溃，pprof 也拿不到完整栈。
-
recover()必须出现在defer函数体内，且该函数尚未返回 - HTTP server 默认不 recover，panic 会直接终止 goroutine 并丢弃堆栈——除非你显式拦截
- 若 panic 发生在
go func() { ... }()里，主 goroutine 无法 recover，必须靠pprof/goroutine或日志定位
pprof 启动时必须暴露 /debug/pprof 且不被中间件拦截
很多项目用 gin/echo 等框架，习惯性把所有路由挂到 /api/xxx 下，却忘了 /debug/pprof 是独立路径，需要显式注册或放行。更隐蔽的问题是反向代理（如 Nginx）或网关默认屏蔽带 /debug/ 的请求，导致 curl http://localhost:8080/debug/pprof/goroutine?debug=2 返回 404 或 403。
- 用
net/http/pprof时，必须执行pprof.Register(pprof.NewProfile("goroutine"))（通常自动完成），但注册不等于暴露 - 若用
http.ServeMux，直接http.HandleFunc("/debug/pprof/", pprof.Index)即可；若用 gin，需r.GET("/debug/pprof/*pprof", gin.WrapH(pprof.Handler())) - 生产环境开启前确认：是否允许未鉴权访问？
/debug/pprof/heap需要运行时 GC 触发才能有数据，不是实时快照
panic 时如何让 pprof 保留足够线索
默认 panic 只打印堆栈到 stderr，进程随即退出，pprof 数据来不及采集。你需要延长进程存活时间，或提前触发 profile 采集。
OpenClaw 基础设施心跳监控与自动恢复：部署/卸载心跳守护进程，配置主机监控（Gateway、磁盘、内存、CPU、进程），设置飞书告警，自动重启故障Gateway。适用关键词：心跳监控、heartbeat daemon、服务器告警、自动重启、健康检查、auto recovery。
立即学习“go语言免费学习笔记（深入）”；
- 在顶层
main函数里加defer+recover，捕获后不立即 exit，而是 sleep 几秒再os.Exit(1)，留给curl /debug/pprof/goroutine?debug=2抓取机会 - 用
runtime.SetPanicHandler（Go 1.19+）替代传统recover，它能在 panic 初始阶段拿到panicv和栈，此时可主动调用pprof.Lookup("goroutine").WriteTo(os.Stderr, 2)输出到日志 - 避免只依赖
pprof/heap：panic 往往和内存无关，goroutine和trace更有用；curl -s "http://localhost:8080/debug/pprof/trace?seconds=5" > trace.out && go tool trace trace.out能看到 panic 前最后几秒的调度行为
recover + pprof 联合排查的真实断点位置
很多人以为 recover 捕获后打印 debug.PrintStack() 就够了，但实际线上 panic 经常发生在第三方库或并发边界，堆栈可能被截断。真正有效的做法是：用 recover 阻止进程退出 → 立即触发 pprof.Lookup("goroutine").WriteTo(f, 2) 写入文件 → 同时记录 panic value 和当前 goroutine id → 最后再 exit。
-
runtime.NumGoroutine()突增 +/debug/pprof/goroutine?debug=2显示大量select或chan receive状态，大概率是 goroutine 泄漏引发的 OOM panic - 如果
pprof/goroutine里看到 panic 相关 goroutine 停在runtime.gopark，说明 panic 发生在 channel 操作或锁竞争处，不是代码显式 panic - 注意
pprof的goroutineprofile 是采样快照，不是全量；想 100% 捕获 panic 点，必须结合SetPanicHandler+ 日志打点，而不是等它发生后再查
最易忽略的一点：pprof 的 goroutine 和 trace 输出依赖 runtime 的内部状态，如果 panic 导致 runtime 被破坏（比如非法指针写入），profile 可能本身就不完整——这时候只能靠提前埋点或 core dump 配合 delve 分析。
