HTTP handler 中 panic 静默返回 500 是因 http.ServeHTTP 默认不 recover，panic 仅输出到 stderr 而非日志系统，需在 handler 最外层用 defer+recover 显式捕获并记录 debug.Stack()。
HTTP handler 中 panic 为什么静默返回 500？
Go 的 http.ServeHTTP 默认不拦截 panic，一旦 handler 内部触发（比如访问 nil map、nil interface{} 调用方法），连接会直接断开，响应体为空，状态码为 500，但服务端日志里通常看不到堆栈 —— 因为 panic 只输出到 os.Stderr，而多数生产日志系统不捕获它。
必须手动加 defer + recover，且中间件中 defer 必须在 h(w, r) 执行前注册，否则无效。常见错误包括：
- 把
defer放在if分支里，导致某些路径没注册 - 只打印
recover()返回的interface{}值，没调用debug.Stack()，查不到哪行代码崩了 - recover 后没显式调用
w.WriteHeader(http.StatusInternalServerError)，依赖框架默认行为，结果返回 200 + 空 body
为什么 Recovery 中间件抓不到 goroutine 里的 panic？
panic 是 goroutine 局部的，不会跨协程传播。你在 http.HandlerFunc 里起一个 go func() { panic("db fail") }()，外面的中间件完全收不到 —— 它只作用于当前 goroutine 栈。
每个独立启动的 goroutine 都得自己包一层 defer + recover，否则会静默退出，留下连接卡住、定时任务漏跑、事务未回滚等隐患。典型场景包括：
立即学习“go语言免费学习笔记（深入）”；
- 消息队列消费者（如
go consume(msg)） - 后台定时清理（
go cleanup()） - 异步日志写入或监控上报
推荐封装通用函数，例如：goSafe(func() { doAsyncWork() })，内部自动加 defer + recover + debug.Stack() 日志。
recover 为什么有时拿不到 panic 值？
recover() 只有在 defer 匿名函数体内**直接调用**才有效。任何间接使用都会失效：
- ❌
r := recover; r()（赋值后再调） - ❌
recover()写在普通函数里，没包在defer func() { ... }()中 - ❌
defer语句出现在panic之后（哪怕只差一行）
还要注意：多个 defer 按后进先出执行，但 recover 所在的 defer 必须在 panic 触发前已注册，顺序不能颠倒。
该不该用 panic 处理业务错误？
不该。Go 的设计哲学是「error 用于可恢复问题，panic 仅用于真正不可继续运行的致命错误」。把参数校验失败、数据库查无结果、JSON 解析错误都塞进 panic，会导致：
- 调用方无法区分「程序崩溃」和「业务拒绝」
- 监控告警失真（所有错误都变成 panic rate 上升）
- 日志爆炸，掩盖真正需要关注的底层故障
真正该用 panic 的场景极少，例如：
- 初始化阶段证书文件读取失败，HTTPS 服务无法启动
- 全局单例（如配置管理器）构造时连接 etcd 失败且无降级路径
- 断言失败（
v, ok := x.(MyType); if !ok { panic(...) }）表明逻辑严重错位
越靠近边界（如 HTTP 入口、goroutine 顶层）越适合 recover；越深入业务层，越该用 error 显式传递 —— 这个分界点，比代码本身更难把握。
