go gin func ErrorMiddleware() gin.HandlerFunc { return func(c *gin.Context) { defer func() { if err := recover(); err != nil { c.IndentedJSON(http.StatusOK, basedto.ResultError(err.(error))) c.Abort() } }() // 处理业务错误 if len(c.Errors) > 0 { // 你可以在这里定义你的错误处理逻辑 golog.Error(jsonutils.ToJsonPretty(c.Errors)) c.JSON(http.StatusInternalServerError, gin.H{"message": "Internal Server Error"}) c.Abort() // 终止请求 } c.Next() } }代码有没有问题

这段代码有严重问题，核心在于c.Errors的检查时机完全错误。以下是逐条分析：

❌ 核心问题

1.c.Errors检查在c.Next()之前 → 永远为空

go

// 此时后续 Handler 还没执行，c.Errors 永远是空的 if len(c.Errors) > 0 { ... } c.Next() // 后续 Handler 在这里才执行

修复：必须放到c.Next()之后。

2.recover()中的类型断言可能二次 Panic

go

err.(error) // 如果 recover 到的不是 error（比如字符串 panic("xxx")），这里会再 panic

虽然 recover 里再 panic 会被 Go 运行时吞掉，但不够安全。

3. 响应写入时机问题

如果 panic 发生在某个 Handler 已经调用了c.JSON()之后，recover 中再次调用c.IndentedJSON会导致"http: superfluous response.WriteHeader call"警告。

✅ 修复后的代码

go

func ErrorMiddleware() gin.HandlerFunc { return func(c *gin.Context) { // 1. 先注册 defer recover（必须在最前面） defer func() { if r := recover(); r != nil { // 安全地处理任意类型 var errMsg string switch e := r.(type) { case error: errMsg = e.Error() case string: errMsg = e default: errMsg = fmt.Sprintf("unknown panic: %v", r) } golog.Error("panic recovered: ", errMsg) // 避免重复写入 if !c.Writer.Written() { c.IndentedJSON(http.StatusOK, basedto.ResultError(errors.New(errMsg))) } c.Abort() } }() // 2. 执行后续 Handler c.Next() // 3. 在 c.Next() 之后检查业务错误 if len(c.Errors) > 0 { golog.Error(jsonutils.ToJsonPretty(c.Errors)) // 取最后一个错误，或合并所有错误 lastErr := c.Errors.Last() if !c.Writer.Written() { c.JSON(http.StatusInternalServerError, gin.H{ "message": lastErr.Error(), }) } // c.Next() 已经执行完，这里不需要 Abort() } } }

🔍 关键差异对照

表格

💡 额外建议

如果你的业务代码是通过c.Error(err)收集错误（而非直接c.JSON返回），建议统一错误码：

go

// 业务 Handler 中 if err != nil { c.Error(err) // 不直接返回，交给中间件统一处理 return // 终止当前 Handler，但继续走中间件 }

如果你已经在 Handler 里直接c.JSON返回错误了，那c.Errors机制就用不上，这个中间件里的c.Errors分支可以删掉，只保留 recover 即可。

需要我帮你改成只处理 panic 的精简版本吗？