对框架开发者而言，delve + pprof + 结构化日志 + context透传组合可覆盖90%线上疑难问题；单靠IDE断点或fmt.Println无法发现goroutine泄漏、竞态、上下文丢失等框架级缺陷。
直接说结论：对框架开发者而言，delve + pprof + 结构化日志 + context 透传，这四样组合能覆盖 90% 的线上疑难问题；光靠 IDE 断点或 fmt.Println 几乎必然漏掉 goroutine 泄漏、竞态、上下文丢失这类框架级缺陷。
delve 调试 goroutine 阻塞和泄漏
框架里大量使用后台 goroutine（比如健康检查、指标上报、连接保活），但它们一旦卡住或没退出，ps aux | grep myapp 看 RSS 持续上涨，top -H -p $PID 会发现线程数越来越多——这时候 IDE 断点根本没用，因为请求早结束了，问题在后台。
- 启动时加
-gcflags "all=-N -l"，否则优化后变量不可见、行号错乱 - 用
dlv exec ./myapp -- --port=8080启动，别用dlv debug（后者会重编译，破坏 build tag 或 init 顺序） - 进调试器后先执行
goroutines，看哪些状态是chan receive或semacquire；再对可疑 ID 执行goroutine $ID bt，确认是否卡在未关闭的time.Ticker.C或空select {} - 别依赖
continue等请求触发——用Ctrl+C中断后直接查 goroutine 状态，更可靠
pprof 抓框架层 CPU 和内存异常
框架封装了中间件、路由分发、序列化逻辑，用户代码还没跑，CPU 就飙高；或者某个接口压测后内存不释放——这些不是业务逻辑问题，而是框架自身开销失控。
- 注册 pprof 必须显式挂载，不能只写
import _ "net/http/pprof"；要在你的 mux/router 里手动注册关键路径：mux.HandleFunc("/debug/pprof/goroutine", pprof.Handler("goroutine").ServeHTTP) - CPU profile 至少采样 30 秒：
go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30，短于 10 秒容易错过中间件反射调用或 JSON 序列化热点 - 查内存泄漏重点看
inuse_space（当前堆占用）和调用栈里的框架函数名，比如github.com/gin-gonic/gin.(*Context).JSON反复出现，说明序列化对象没被 GC 回收 - 生产环境禁用
/debug/pprof/cmdline和/debug/pprof/profile全量暴露，只开/goroutine?debug=2和/heap即可
结构化日志 + context.Value 透传 trace_id
框架处理一个请求，可能横跨多个中间件、goroutine、HTTP 客户端调用；如果日志里只有时间戳和行号，你根本分不清哪几条 log 属于同一次请求，更别说定位哪个中间件 panic 了。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 别用标准
log包——它不支持字段注入，也拿不到context；改用zap或zerolog，并确保初始化时绑定context.Context - 在入口 middleware（如 Gin 的
Use）里从r.Header.Get("X-Trace-ID")提取并存入ctx = context.WithValue(r.Context(), traceKey, traceID) - 所有后台 goroutine 启动前必须带 context：
go handleAsync(ctx, data)，而不是go handleAsync(data)；否则ctx.Done()永远不会触发，goroutine 就成了孤儿 - 日志输出必须包含
trace_id字段；如果某条 log 缺失该字段，说明 context 在某处被丢弃，大概率发生在 channel send/receive 或第三方库回调中
recover 捕获框架 panic 但别吞掉 stack trace
框架里大量使用 reflect、unsafe、动态注册 handler，一出错就是 panic；但直接 recover() 后只打印 "panic occurred"，等于把最宝贵的诊断信息扔了。
- 每个顶层 goroutine（包括
http.HandlerFunc、time.AfterFunc、go func()）都应包一层defer+recover -
recover()后必须立刻用debug.PrintStack()或fmt.Printf("%+v", debug.Stack())输出完整栈帧，不能只打err.Error() - panic 信息要写入结构化日志（带
level=error和stack字段），并上报到集中式日志系统；否则重启后就再也看不到现场了 - 注意：不要在
recover里尝试“恢复”状态（比如重置全局 map），Go 的 panic 不保证内存一致，强行继续运行可能引发更隐蔽的崩溃
框架调试真正的难点不在工具怎么用，而在于你得时刻意识到：你写的不是单个函数，而是一套运行时环境。goroutine 生命周期、context 传播边界、panic 的传染路径、pprof 的采样窗口——这些都不是业务代码关心的事，但它们决定了框架是否扛得住真实流量。漏掉其中任意一环，问题就会从“能复现”退化成“偶发、无法定位、只能重启”。
