panic堆栈默认不显示真实业务行号，因仅打印当前goroutine活跃帧，经runtime函数（如servehttp）后上层业务函数被截断；需在recover中显式调用debug.stack()获取含“created by”的完整调用链。
panic堆栈里为什么看不到真实业务代码行号
默认 panic 日志只打印当前 goroutine 的活跃调用帧，一旦中间经过 runtime 函数（比如 http.HandlerFunc.ServeHTTP、runtime.gopark），上层业务函数就被截断了。你看到的可能是 “created by net/http.(*Server).Serve” 而不是你自己的 userHandler 函数名。
真正能拿到完整调用链的是 debug.Stack()，它返回所有 goroutine 的快照，包含 created by 行——这行才是定位 panic 源头的关键。
- 在
recover的 defer 里必须显式调用debug.Stack()，不能只打r - 加
//go:noinline注释防止编译器内联掉上层帧 -
debug.Stack()返回[]byte，记得转成string再写日志，否则日志里是内存地址
HTTP handler 中 recover 失效的三个典型场景
不是 recover 写错了，而是 panic 发生在它管不到的地方：主 handler 的 defer 只对当前 goroutine 有效。
- 子 goroutine panic：比如你在 handler 里写了
go sendLog()，而sendLog里访问了 nil 指针——主 handler 的 defer 根本捕获不到 - 第三方中间件拦截了 panic：Gin 的
gin.Recovery()默认只处理主流程，若你在中间件之后又起 goroutine，它不覆盖 - init 阶段 panic：main 函数还没跑起来，
init里出错，handler 层的 recover 完全没机会执行
如何让 panic 日志带上 traceID 和上下文
线上服务里单靠堆栈无法关联请求，必须把业务上下文注入 panic 日志。
- 不要在全局
defer里硬编码 traceID；改用 context.Value 透传，recover 时从context.TODO()或显式保存的 ctx 取值 - 避免在
recover里调用可能 panic 的函数（比如未判空的log.WithFields()） - 推荐结构：先记录
traceID+panic value+debug.Stack()三段式日志，再发告警
safeGo 封装必须检查的两个细节
你写的 safeGo 很可能漏掉关键防护点。
- 必须在 goroutine 内部做
defer func() { recover() }()，而不是在外部包一层就完事——因为 panic 一旦发生，外部函数早已返回 - recover 后要主动记录日志，不能只
log.Printf；至少包含 goroutine ID、启动位置（runtime.Caller(1)）、和原始 panic 值 - 如果 goroutine 是定时任务（如
time.Ticker触发），recover 后建议 sleep 后继续，避免死循环打满 CPU
debug.Stack() 里的 created by 行和 goroutine 状态标记（[chan receive]、[semacquire]）比 panic 行号更有诊断价值。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
