go 的 http.server 默认不捕获 handler 中 panic，因其设计上不提供隐式异常兜底，panic 仅导致当前 goroutine 崩溃、连接关闭，而服务继续运行，请求静默失败；必须显式用 defer+recover 在 handler 入口前注册才能捕获并返回 500。
HTTP handler 中 panic 为什么没被自动捕获
Go 的 http.Server 默认不会拦截 handler 内部的 panic，也不会返回 500。它只会打印堆栈到日志、关闭连接，然后让 goroutine 死掉——整个服务还在跑，但这个请求已“静默失败”。这不是 bug，是设计使然：Go 不提供隐式异常兜底。
常见现象包括：
- 前端收到空响应或连接中断，而非
500 Internal Server Error - 日志里只有一行
http: panic serving ...: ...，没有上下文、无 traceID、无法关联请求 - 中间件（如 JWT 验证、日志记录）在 panic 后不再执行，资源未清理
解决方式必须显式包装：每个 handler 或中间件入口加 defer + recover，且必须放在 handler 执行前注册。
如何写一个安全的 recover 中间件
直接在 handler 里写 defer 容易漏写、重复、难统一。推荐封装成中间件，但要注意几个硬性约束：
-
defer必须在next.ServeHTTP()之前调用，否则注册失效 -
recover()只能在defer函数体内调用才有效，不能提前提取变量 - 若
w.Header().WasWritten()已为true（比如中间件已写入部分响应），再调http.Error()会触发二次 panic - 建议用
debug.Stack()获取原始栈，而非debug.PrintStack()（后者直接输出到 stderr，不可控）
示例中间件：
func recoveryMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
buf := debug.Stack()
log.Printf("PANIC in %s %s: %v\n%s", r.Method, r.URL.Path, r, buf)
if !w.Header().WasWritten() {
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
}
}()
next.ServeHTTP(w, r)
})
}
goroutine 里的 panic 为什么 recover 不了
这是最常被误解的一点：recover 只对**当前 goroutine** 有效。你在主 handler 里 defer 了 recover，但里面起的 go func() { panic("x") }()，这个 panic 永远不会被主 goroutine 的 recover 捕获。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
典型翻车场景：
- 异步写日志、发消息、清理缓存时 panic，整个 goroutine 消失，无日志、无告警、无重试
- worker pool 中某个任务 panic，导致该 worker goroutine 退出，但 pool 不感知、不替换
正确做法是：每个可能 panic 的 goroutine 入口处，自己包一层 defer func() { recover() }()。不要指望外层兜底。
例如：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("worker panic: %v", r)
// 这里可发告警、上报 metric、触发重试逻辑
}
}()
doWork()
}()
recover 后还能继续执行业务逻辑吗
能，但非常危险——recover 只停止 panic 传播，不修复任何状态。map 还是 nil、channel 还是 closed、数据库事务早已回滚或未提交，这些你都得自己处理。
- 不要在关键路径（如支付扣款、库存扣减）中依赖
recover继续流程；应立即返回错误、记录上下文、终止该请求 - 如果必须恢复，只做两件事：清理资源（
close(file),tx.Rollback()）、返回明确错误码 - 类型断言很重要：
r是interface{}，可能是string、error、自定义 struct，直接fmt.Println(r)易丢失信息
推荐判别方式：
switch err := r.(type) {
case string:
log.Printf("panic string: %s", err)
case error:
log.Printf("panic error: %v", err)
default:
log.Printf("panic unknown type: %T, value: %+v", r, r)
}
真正容易被忽略的是：recover 不是万能补丁。它只适合边界防护（如 HTTP handler、goroutine 入口），绝不该用于掩盖逻辑缺陷或替代 proper error handling。panic 的根源——比如未初始化的 map、未检查的 nil interface{}——必须从源头修复，而不是靠 recover 挡着。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
