能，但仅限于同一goroutine中、且必须在panic发生前已启动的defer函数内调用；recover无法跨goroutine生效，不能替代错误处理或掩盖设计缺陷。

Go事件处理器里能用recover捕获panic吗？

能，但仅限于**同一goroutine中、且必须在panic发生前已启动的defer函数内调用**。Go的recover不是全局异常拦截器，它无法跨goroutine生效——这意味着如果你的事件处理器（比如HTTP handler或消息回调）启用了新goroutine执行业务逻辑，直接在handler顶层defer里写recover是无效的。

HTTP handler中正确使用recover的姿势

典型错误是把recover放在handler外层，却让实际业务跑在另一个goroutine里。正确做法是把recover绑定到真正可能panic的执行路径上：

func myHandler(w http.ResponseWriter, r *http.Request) {
    // 这个defer只管当前goroutine，有效
    defer func() {
        if r := recover(); r != nil {
            http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            log.Printf("panic in handler: %v", r)
        }
    }()

    // 所有业务代码必须在这里同步执行
    processData(r) // 可能panic
    renderResponse(w)
}

• 不要在defer里调用recover()后继续写业务逻辑——recover只阻止panic传播，不恢复执行栈
• 如果业务逻辑里显式启了goroutine（如go doAsync()），那个goroutine里的panic必须在它内部自己defer recover()
• recover()返回nil时代表没发生panic，别把它当错误码判断

为什么recover在中间件里经常失效？

常见于用http.HandlerFunc链式包装的中间件。问题出在调用顺序和goroutine边界：

Miller CSV TSV JSON 数据处理器

Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。

下载

• 中间件A的defer recover()只能捕获A内部panic，不能捕获它调用的handlerB里的panic——除非B也在自己的作用域里做了defer
• 如果中间件用了go func() {...}()异步处理日志或监控，那个goroutine的panic完全逃逸出recover范围
• 第三方库（如某些RPC client）内部抛panic，而你没控制它的调用上下文，recover也无能为力

替代方案比硬套recover更可靠

依赖recover做错误兜底容易掩盖设计缺陷。更健壮的做法是：

• 对输入做严格校验，避免nil解引用、数组越界等可预防panic
• 用errors.Is和自定义错误类型代替panic传递业务错误
• 在goroutine启动处统一包一层recover： go func() { defer recover(); work() }()
• HTTP服务启动时用http.Server.ErrorLog捕获未被recover的panic（需配合RecoverFromPanic类中间件）

真正难缠的是那些发生在CGO调用、信号处理或运行时内存耗尽时的崩溃——recover对此完全无效，得靠进程级监控和core dump分析。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！