Go · defer / panic / recover

场景 1 · 中间件 recover: 单请求 panic 不拖死整个服务

一个 handler 里的 nil 指针 panic 会把整条连接打断, 监控只看到 connection reset; 统一兜住才有 500 可查:

func recoverMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if rec := recover(); rec != nil {          // 只能在这里直接调
                log.Printf("panic: %v\n%s", rec, debug.Stack())
                if r.Context().Err() != nil {
                    return                              // 客户端已断开: 补写响应无意义
                }
                w.Header().Set("Content-Type", "application/json")
                w.WriteHeader(http.StatusInternalServerError)
                json.NewEncoder(w).Encode(errResp{Code: "internal_error"})
            }
        }()
        next.ServeHTTP(w, r)                                // 业务 handler 的 panic 全被兜住
    }()
}

场景 2 · 文件 Close 三段式: 先查错, 再 defer, 后 Sync

无脑 defer f.Close() 会吞掉 Close 的错误 —— 页缓存没刷完就是静默丢数据:

f, err := os.Create(path)
if err != nil {
    return err                                              // ① 失败就别注册 defer (nil f 会 panic)
}
defer func() {                                          // ③ 收尾: Close 的错误不能丢
    if cerr := f.Close(); cerr != nil {
        err = errors.Join(err, fmt.Errorf("close %s: %w", path, cerr))
    }
}()
if _, werr := f.Write(buf); werr != nil {                   // ② 主逻辑
    return werr
}
return f.Sync()                                         // Close 不保证刷盘, 账单类数据要 Sync

场景 3 · 锁的 defer Unlock 模板: 提前 return 也不漏解锁

手写 Unlock 的函数每加一个 return 分支就多一个死锁隐患; defer 一注册全兜住:

func (c *Cache) GetOrLoad(k string) (Item, error) {
    c.mu.RLock()
    hit, ok := c.m[k]                                       // 读锁内只做快速路径
    c.mu.RUnlock()
    if ok {
        return hit, nil
    }
    c.mu.Lock()                                             // 慢路径升级写锁
    defer c.mu.Unlock()                                     // 之后 4 个 return 分支都不用记得解锁
    if hit, ok := c.m[k]; ok {                              // double-check: 等锁期间可能已被填上
        return hit, nil
    }
    v, err := load(k)
    if err != nil {
        return Item{}, err                                 // 提前返回, defer 保证解锁
    }
    c.m[k] = v
    return v, nil
}

场景 4 · 命名返回值 + defer: 统一错误包装与指标上报

五处 return 就要写五次包装和打点; 挂在 defer 里一处收口:

func (s *Service) Call(ctx context.Context, req *Req) (resp *Resp, err error) {
    started := time.Now()
    defer func() {                                          // 命名返回值: 这里改的 err 就是返回值
        cost := time.Since(started)
        if err != nil {
            err = fmt.Errorf("service=%s req_id=%s cost=%s: %w",
                s.name, req.ID, cost, err)                  // %w 包装: 上层 errors.Is 仍可用
            s.metrics.ErrTotal.WithLabelValues(s.name).Inc()
            return
        }
        s.metrics.CostMS.WithLabelValues(s.name).Observe(float64(cost.Milliseconds()))
    }()
    resp, err = s.doCall(ctx, req)                          // 注意用 = 不是 :=, 否则遮蔽返回值
    return
}

场景 5 · 事务兜底: defer Rollback 的无 commit 即回滚

SQL 事务三步写完, 中间任何 return 都要回滚; defer 让"忘记回滚"从代码里消失:

func (s *Store) CreateOrder(ctx context.Context, o Order) error {
    tx, err := s.db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback()                                     // commit 成功后 Rollback 返回 ErrTxDone, 无害
    if _, err := tx.ExecContext(ctx, insertOrderSQL, o.ID, o.Amount); err != nil {
        return err                                          // 这里返回 → defer 回滚
    }
    if _, err := tx.ExecContext(ctx, deductStockSQL, o.SKU, o.Qty); err != nil {
        return err                                          // 同上: 任何失败路径统一被兜
    }
    if _, err := tx.ExecContext(ctx, insertLedgerSQL, o.ID, o.Amount); err != nil {
        return err
    }
    return tx.Commit()                                      // 走到这里才提交; 没提交的都回滚
}

场景 6 · 循环里 defer 泄漏事故: 50 万文件导出拖垮进程

导出循环里 defer f.Close(), 函数不返回 defer 不执行 —— fd 一路涨到 ulimit:

// 事故: exportAll 循环 50 万个文件, 每个都 defer f.Close()
// 症状: lsof 一路涨, 半小时后 "too many open files", 进程卡死
func exportAll(paths []string) error {
    for _, p := range paths {
        if err := exportOne(p); err != nil {                // 修复: 每文件一个函数作用域
            return err
        }
    }
    return nil
}
func exportOne(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close()                                         // 函数结束立即执行, 不再堆积
    return streamTo(f)
}

修复后 lsof 稳定在个位数; 数据量小也可在循环体内显式 Close, 但函数封装最不易漏。

场景 7 · panic 哨兵值: 深递归里带错误快速撤退

几十层递归里逐层 if err 判空太啰嗦; 哨兵 panic + recover 转错误是标准解法 (stdlib template/JSON 解码同款):

var errAbortWalk = errors.New("walk aborted")

func walkTree(n *Node, visit func(*Node) error) (err error) {
    defer func() {
        if r := recover(); r != nil {
            if r == errAbortWalk {                          // 哨兵 panic: 最快退出通道
                err = errAbortWalk                          // recover 转成正常错误返回
                return
            }
            panic(r)                                          // 别的 panic 原样再抛: 不吞现场
        }
    }()
    eachNode(n, visit)
    return nil
}
// 调用方: visit 返回 errAbortWalk 时内部直接 panic, 免掉逐层判空

场景 8 · goroutine panic 上报: 统一 Go 出口配 Sentry

裸 go func() 起的后台任务一旦 panic 就是全进程 exit 2, 半夜被告警叫醒; 统一出口拦住并上报:

func Go(name string, fn func()) {                           // 项目统一的 go 出口
    go func() {
        defer func() {
            if r := recover(); r != nil {
                stack := debug.Stack()                      // 此刻不拍, 栈就被展开收走了
                sentry.CaptureException(fmt.Errorf("goroutine %s panic: %v\n%s", name, r, stack))
                log.Error("goroutine panic", "name", name, "panic", r)
            }
        }()
        fn()
    }()
}
// 用法: Go("order-consumer", consume) — 子任务崩了只上报, 不拖死整个进程

场景 9 · 优雅停机: defer 逆序收尾资源

启动顺序 listener → DB → MQ, 停机必须逆序: 先停流量再关依赖, defer 的 LIFO 天然就是这张图:

func run(ctx context.Context) error {
    lis, err := net.Listen("tcp", ":8080")
    if err != nil {
        return err
    }
    defer lis.Close()                                         // 后开的最先关: 与启动顺序互为镜像
    db, err := sql.Open("mysql", dsn)
    if err != nil {
        return err
    }
    defer db.Close()                                          // 连接池在 listener 之后收
    sub, err := mq.Subscribe(ctx, topic, handler)
    if err != nil {
        return err
    }
    defer sub.Unsubscribe(ctx)                                // 先停流量, 再关依赖
    return http.Serve(lis, makeMux())                        // ctx 取消 → Serve 返回 → defer 逆序收尾
}

场景 10 · recover 后 ResponseWriter 已写一半: 499 场景处置

流式下载写了一半 panic, 客户端早已超时断开 —— 这时补 500 既不可能也没人收:

defer func() {
    if rec := recover(); rec != nil {
        log.Printf("panic: %v\n%s", rec, debug.Stack())
        if r.Context().Err() != nil {
            return                                          // 499: 客户端已断开, 写了也没人收
        }
        if w.Header().Get("Content-Length") == "" && !written(w) {
            w.Header().Set("Content-Type", "application/json")
            w.WriteHeader(http.StatusInternalServerError)     // 只有没写过 header 才能补 500
            json.NewEncoder(w).Encode(errResp{Code: "internal"})
            return
        }
        // 已写一半 (流式下载中断): 只能记日志, 连接交给 server 断
        log.Error("partial response abandoned", "path", r.URL.Path)
    }
}()
// written(w): 中间件包一层响应记录器, 记录 WriteHeader/Write 是否已被调用