必须启用debug.settraceback("all")才能获取完整调用栈，否则默认仅输出顶层函数；recover仅对同goroutine内defer链中的panic有效，跨goroutine或defer执行顺序错误将导致捕获失效。
panic发生时如何获取完整调用栈
Go的panic默认只打印错误信息和顶层函数名，关键中间调用链常被截断。必须启用完整栈追踪，否则无法定位真实出错位置。
在程序启动时加这行代码：
debug.SetTraceback("all")，它会让runtime输出所有goroutine的完整调用帧（包括内联函数、未导出方法）。不加这句，你看到的可能是main.main或runtime.goexit这种无意义入口。
常见误区是只依赖recover捕获后的debug.PrintStack()——它只打当前goroutine栈，而panic可能由其他goroutine触发且已退出，此时什么也捞不到。
如何快速定位nil指针解引用的panic
最常见panic是panic: runtime error: invalid memory address or nil pointer dereference，但Go不会告诉你哪个变量为nil、在哪一行解引用。
实操建议：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 编译时加
-gcflags="-l"禁用内联：go build -gcflags="-l" main.go
，避免内联导致行号错乱 - 用
go run -gcflags="-l" main.go直接运行，panic时的行号更可信 - 对疑似结构体字段访问前加显式判空，例如
if p != nil && p.cfg != nil，而不是直接写p.cfg.Timeout - 启用Go 1.21+的
GOEXPERIMENT=arenas可让部分nil panic附带字段名提示（非稳定特性，仅作参考）
recover没生效？检查goroutine隔离和defer执行顺序
recover只对**同一goroutine中、同一层defer链里**发生的panic有效。跨goroutine、或defer已返回后再panic，recover完全静默。
典型失效场景：
- 在goroutine里起新goroutine并panic：
go func() { panic("boom") }()—— 主goroutine的recover捕不到 - 多个defer嵌套，但
recover写在了错误的位置：defer func() { recover() }() // 这个能捕到<br>defer func() { panic("now") }() // 但这个panic发生在recover之后 - HTTP handler里写了
recover，却忘了它只作用于handler函数体内，不覆盖中间件或底层net/http的panic
生产环境panic日志怎么不丢失
默认panic输出到os.Stderr，容器环境下容易被截断或混入其他日志，且进程退出后日志即消失。
必须重定向：
- 启动时把标准错误重定向到文件：
./app 2>&1 | tee panic.log
- 在代码里替换
os.Stderr：log.SetOutput(os.Stdout) // 或自定义Writer<br>os.Stderr = os.Stdout
，确保panic输出和业务日志同源 - 用
signal.Notify监听syscall.SIGQUIT，手动触发debug.Stack()快照，比等panic更主动
别依赖日志采集agent自动抓取stderr——很多agent只采stdout，或有缓冲延迟，panic瞬间进程就死了，日志根本来不及上报。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
