Go panic堆栈默认不完整，需在defer+recover后立即用runtime.Stack预分配4KB缓冲抓取；Gin等框架中间件panic常掩盖真实行号，须在可疑处手动recover并打印；子goroutine panic无法被handler recover捕获，需safeGo封装；主goroutine和handler顶层均需兜底recover。
panic堆栈默认不完整，得手动抓取
Go 默认 panic 堆栈只输出当前 goroutine 的活跃帧，且 runtime.Stack() 在 recover 后若不立即调用，可能被清理或截断。Gin 等框架的 Recovery 中间件虽调用了 debug.PrintStack()，但若日志被重定向（如 gin.DefaultWriter = io.Discard），就等于白写。
- 预分配至少 4KB 缓冲区：
buf := make([]byte, 1024*4)，再传给runtime.Stack(buf, false) - 必须在
defer+recover()后**立刻执行**，中间不能有其他函数调用 - 别用
fmt.Printf("%s", debug.Stack())——debug.Stack()返回[]byte，直接转 string 更安全 - 线上环境禁用
gin.DebugMode，改用自定义 Recovery 中间件控制日志输出位置和格式
中间件里 panic 堆栈常指向 c.Next()，不是真出错点
Gin 的中间件执行链是 middleware1 → c.Next() → middleware2 → handler，一旦 panic 发生在某个中间件内部，Go 默认堆栈会把 c.Next() 当作顶层调用点，真实行号被掩盖。
- 在可疑中间件开头加
defer func() { if r := recover(); r != nil { log.Printf("PANIC in AuthMiddleware: %v", r); debug.PrintStack() } }() - 避免在中间件里写
panic(fmt.Errorf("xxx"))，改用c.AbortWithStatusJSON(401, ...)显式返回错误 - 通用日志中间件可用
runtime.Caller(1)获取调用该中间件的 handler 文件名和行号，辅助关联
第三方库 panic 堆栈缺失上下文，需在 handler 顶层兜底
像 json.Unmarshal(nil, &v)、template.Execute(..., nil) 或 gorm.First(&u, 1) 对未初始化 struct 指针操作，panic 堆栈往往止步于标准库或 SDK 内部，看不到你自己的代码行。
- 每个 HTTP handler 函数第一行加
defer func() { if p := recover(); p != nil { log.Printf("[HANDLER PANIC] %s %s: %v", c.Request.Method, c.FullPath(), p); debug.PrintStack() } }() - 高危操作前做防御：解包前检查
len(body) > 0，查库前确认u != nil，模板渲染前判空if v == nil { c.AbortWithStatusJSON(400, ...) } - 对已知易 panic 的调用（如
yaml.Unmarshal、xml.Decode）统一封装一层带 error 判断的 wrapper，不依赖 panic 流程
子 goroutine panic 完全逃逸 handler recover
HTTP 请求由独立 goroutine 处理，但你在 handler 里起的子 goroutine（比如异步上报、定时清理、回调通知）一旦 panic，外层 defer recover() 根本捕获不到——这是最常被忽略的漏网点。
立即学习“go语言免费学习笔记（深入）”；
- 所有显式
go fn()必须包裹safeGo()：内部自带defer recover()并记录日志 - 不要在 handler 内裸写
go func() { ... }()；改用封装好的 runner，例如：safeGo(func() { doAsyncWork() }) -
main()函数开头也加defer recover()，覆盖 init 阶段或主 goroutine 的早期 panic -
debug.SetPanicOnFault(true)对业务 panic 无效，仅限非法内存访问（如某些平台的 nil dereference 触发 SIGSEGV），别指望它兜底
debug.Stack()。 
