http handler 中 panic 默认不返回 500，因 http.server 不捕获 panic，仅关闭连接、打印堆栈到 stderr，前端收空响应或 connection reset；必须显式 defer+recover 且在 next.servehttp 前注册，recover 仅对同 goroutine 有效。
http.Handler 中的 panic 为什么默认不返回 500
Go 的 http.Server 明确设计为不捕获 handler 内 panic —— 它只打印堆栈到日志、关闭连接，然后让当前 goroutine 死掉。请求不会返回 500 Internal Server Error，前端可能收空响应或 connection reset，日志里只有模糊的 http: panic serving ...，且中间件（如 JWT 验证、日志记录）在 panic 后不再执行。
- 这不是 bug，是 Go 的显式性哲学：不提供隐式兜底，避免掩盖逻辑错误
- 必须在每个 handler 入口或中间件中显式注册
defer+recover - 若用第三方路由库（如 Gin、Echo），它们通常已内置 recovery 中间件，但需确认是否启用及日志是否带 traceID
写 recover 中间件时最常踩的三个坑
封装成中间件是统一处理 panic 的推荐方式，但以下三点不注意就会失效或引发二次 panic：
-
defer必须在next.ServeHTTP()之前注册，否则 panic 发生时该defer还没入栈 -
recover()只能在defer函数体内调用才有效；写成if r := recover(); r != nil { ... }在普通作用域里永远返回nil - 调用
http.Error()前必须检查w.Header().WasWritten()，否则当 header 已被前序中间件写入（如 CORS、gzip），会触发http: multiple response.WriteHeader calls二次 panic
goroutine 里的 panic 为什么 recover 不了
这是最普遍的误解：recover 只对**当前 goroutine** 有效。你在主 handler 里 defer 了 recover，但里面起的 go func() { panic("x") }()，这个 panic 永远不会被主 goroutine 捕获。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 典型翻车场景：异步发消息、清理缓存、写审计日志时 panic，整个 goroutine 消失，无日志、无告警、无重试
- 正确做法：每个关键 goroutine 都要独立加
defer func() { if r := recover(); r != nil { ... } }() - 不要把 recover 放在全局 goroutine 池（如
sync.Pool复用的 worker）外层——它只管自己那一个 goroutine
哪些 panic 实际上无法可靠 recover
不是所有 panic 都能被 recover 拦住。以下运行时 panic 通常无法安全捕获，或捕获后程序状态已不可信：
-
nil pointer dereference：解引用空指针，recover 可能成功，但栈已损坏，继续执行风险高 -
concurrent map writes：并发写 map 触发的 panic 极难 recover，且 Go 运行时可能直接终止程序 -
send on closed channel：向已关闭 channel 发送数据，recover 虽可捕获，但 channel 状态已不可逆 - 这些情况更应靠预防：用
sync.Map替代原生 map，加select { case ch 避免阻塞发送，严格管理 channel 生命周期
真正需要关注的，不是“能不能 recover”，而是“panic 是否暴露了本该用 error 处理的业务路径”。比如数据库查询失败、参数校验不通过，这些绝不该 panic，而应返回 error 并由上层决定重试或降级。recover 只应兜底那些你没料到、又不想让整个服务挂掉的意外崩溃。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
