HTTP handler 中 panic 不会终止服务但会导致请求静默失败，需在每个 handler 或中间件中手动 defer+recover 兜底；main/init 中 panic 无法被捕获，goroutine 内 panic 必须各自 recover。

HTTP handler 里 panic 不会杀掉整个服务，但请求会静默失败

Go 的 http.ServeHTTP 对每个请求启动独立 goroutine，所以单个 handler panic 只终止那个 goroutine，进程照常运行——这是好事，也是陷阱。你看到服务没挂，但前端收不到响应、日志里也没错误，只有一行被吞掉的 panic 堆栈（标准库会 log，但不写回 response）。

• 现象：访问 /api/user/123 返回空白或连接超时，curl -v 显示 0 字节响应，log.Fatal 没触发
• 原因：标准库在 server.go 内部做了 recover，但仅用于记录，不调用 http.Error
• 必须手动在每个 handler 或中间件里加 defer + recover，否则就是“服务活着，请求死了”
• 别信“全局中间件就够了”——如果 panic 发生在中间件之后（比如业务函数里），而 handler 本身没包 defer，照样漏捕

用 recoverMiddleware 包裹 handler 是最简可行方案

不是所有 panic 都该被 recover，但 HTTP 入口必须兜底。推荐写一个轻量中间件，在 defer 里调 recover，并统一返回 JSON 错误。

• 示例结构：

  func recoverMiddleware(next http.HandlerFunc) http.HandlerFunc {
      return func(w http.ResponseWriter, r *http.Request) {
          defer func() {
              if r := recover(); r != nil {
                  log.Printf("PANIC in %s %s: %+v", r.Method, r.URL.Path, r)
                  http.Error(w, "Internal Server Error", http.StatusInternalServerError)
              }
          }()
          next(w, r)
      }
  }

• 注册时显式包装：http.HandleFunc("/user", recoverMiddleware(userHandler))
• 注意：别在 recover 里做耗时操作（如写磁盘、发告警 HTTP 请求），会阻塞该 goroutine，拖慢后续请求
• 堆栈要打全：debug.PrintStack() 比 fmt.Sprintf("%+v", r) 更有用，尤其对嵌套 panic

main 函数和 init 阶段的 panic 无法被 HTTP 层捕获

如果 panic 发生在 main() 函数里（比如监听端口失败没检查 error）、或包初始化（init）中，HTTP server 根本没起来，recover 就没机会运行——进程直接退出。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 必须在 main 开头加顶层 defer：

  func main() {
      defer func() {
          if r := recover(); r != nil {
              log.Fatalf("FATAL PANIC in main: %+v", r)
              os.Exit(1)
          }
      }()
      http.ListenAndServe(":8080", mux)
  }

• init 函数里不能 recover，所以任何初始化逻辑（读配置、连 DB）都要用 error 判断，绝不能 panic —— 否则服务起不来，运维连日志都看不到
• 第三方库若在 init 里 panic（极少见），只能换库或提 issue

goroutine 里的 panic 必须各自 recover，别指望“主流程兜底”

Go 的 goroutine 是隔离的，子 goroutine panic 不会传播到父 goroutine，但会导致该 goroutine 终止，并可能泄漏资源（如未关闭的文件、DB 连接）。更危险的是：某些 runtime 场景下（如所有非 daemon goroutine 都死光），进程仍会退出。

立即学习“go语言免费学习笔记（深入）”；

• 错误写法：go riskyFunc() 然后以为外面能 catch —— 不可能
• 正确做法：每个长期运行或不可信逻辑的 goroutine 内部自己加 defer + recover
• 可封装成工具函数：safeGo(func() { ... })，内部自动包一层 defer/recover
• 使用 errgroup.Group 或 context.WithCancel 管理 goroutine 生命周期，比裸写 go 更安全

真正难的不是写那几行 defer/recover，而是判断哪里该 panic、哪里该 return error、哪里又必须 recover。这三个边界模糊的地方，才是线上事故最多发的位置。