如何为Go语言中间件添加recover异常恢复-Golang-PHP中文网

recover必须在defer中直接调用且defer须在panic前注册，否则失效；仅捕获同goroutine panic，不能替代error处理，http中间件中需在next.servehttp()前注册defer并检查响应头状态。

如何为go语言中间件添加recover异常恢复

Go中间件里recover没生效？检查defer位置和panic发生时机

Go的recover必须在defer函数中调用，且该defer必须在panic发生前已注册——这是中间件中recover失效最常见的原因。很多开发者把defer recover()写在中间件函数末尾，但此时panic早已在后续next.ServeHTTP()中触发，而defer已执行完毕。

正确做法是：在调用next.ServeHTTP()前就注册带recover逻辑的defer：

func RecoverMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 必须在这里注册 defer，才能捕获 next.ServeHTTP 中的 panic
        defer func() {
            if err := recover(); err != nil {
                http.Error(w, "Internal Server Error", http.StatusInternalServerError)
                log.Printf("Panic recovered: %v", err)
            }
        }()
        next.ServeHTTP(w, r) // panic 可能发生在这里
    })
}

defer语句必须出现在next.ServeHTTP()之前，否则无法捕获其内部panic
不要在defer里直接调用recover()（如defer recover()），它会立即执行并返回nil；必须包裹在匿名函数中
如果中间件链中存在多个recover中间件，只有最内层（离handler最近）的那个能捕获panic，外层不会触发

recover后如何安全地继续响应？避免write after write header错误

recover之后不能假设ResponseWriter还处于可写状态——如果panic前已有w.WriteHeader()或w.Write()调用，再写入就会触发http: superfluous response.WriteHeader call或http: multiple response.WriteHeader calls错误。

标准做法是：recover后立即检查w是否已写头，若已写则放弃自定义错误响应，只记录日志：

defer func() {
    if r := recover(); r != nil {
        // 检查是否已写header（通过判断w.Header().Get("Content-Type")是否非空等启发式方式）
        // 更可靠的方式：包装ResponseWriter，记录WriteHeader是否被调用（见下节）
        if !wroteHeader(w) {
            http.Error(w, "Internal Server Error", http.StatusInternalServerError)
        }
        log.Printf("Recovered from panic: %v", r)
    }
}()

Go标准http.ResponseWriter不暴露“是否已写头”接口，生产环境建议用httptest.ResponseRecorder或自定义wrapper记录状态
不要在recover后尝试读取r.Body或修改r.Context()，请求可能已损坏或超时
若需返回结构化错误（如JSON），确保Content-Type头已显式设置，且未被之前中间件覆盖

为什么用http.StripPrefix + http.FileServer时recover不生效？

因为http.FileServer内部panic（比如路径遍历失败、文件打开权限错误）不会透出到你的中间件作用域——它由http.ServeFile或底层os.Open触发，并在FileServer自己的http.Handler中处理或直接崩溃进程。

OC SSH Tunnel Node Recovery

诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。

下载

解决方法只有两种：

不用http.FileServer，改用自己实现的静态文件handler，在其中包裹defer/recover
在FileServer外再套一层handler，用io.MultiReader或http.TimeoutHandler等间接控制，但无法捕获其内部panic
更实际的做法：对静态资源路径做白名单校验，提前拦截非法路径，从源头避免panic（例如拒绝..、空字节、控制字符）

例如，在StripPrefix后加一层路径过滤：

func SafeFileServer(root http.FileSystem) http.Handler {
    fs := http.FileServer(root)
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 提前校验路径，避免FileServer内部panic
        if strings.Contains(r.URL.Path, "..") || strings.HasPrefix(r.URL.Path, "/.") {
            http.Error(w, "Forbidden", http.StatusForbidden)
            return
        }
        fs.ServeHTTP(w, r)
    })
}

recover无法捕获goroutine泄漏或context取消导致的panic？

能。但要注意：recover只对**当前goroutine**有效。HTTP handler通常运行在独立goroutine中，所以中间件里的defer/recover可以捕获该goroutine内的panic。但如果panic发生在子goroutine（比如go func(){ ... panic() }()），主goroutine的recover完全无感知。

这类场景必须单独处理：

所有显式启动的goroutine，都应在内部加defer recover()，且最好将错误发到channel或log中
使用context.WithCancel或context.WithTimeout时，panic不会因context取消而自动触发；但若你在取消后继续操作已关闭的channel或mutex，可能引发panic——这类需靠代码审查和测试发现
第三方库（如数据库驱动、模板渲染）若在goroutine中panic，且未提供错误回调，你就只能靠全局signal.Notify捕获SIGABRT等信号，但这已超出recover范畴

真正容易被忽略的是：recover不恢复栈，也不重置defer队列。一旦panic发生，当前函数的defer按逆序执行，但之后的代码（包括其他defer）不再运行。这意味着你不能靠recover来“重试”或“回滚事务”，它只是防止进程崩溃的兜底机制。