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()中的类型断言可能二次 Panicgoerr.(error) // 如果 recover 到的不是 error比如字符串 panic(xxx)这里会再 panic虽然 recover 里再 panic 会被 Go 运行时吞掉但不够安全。3. 响应写入时机问题如果 panic 发生在某个 Handler 已经调用了c.JSON()之后recover 中再次调用c.IndentedJSON会导致http: superfluous response.WriteHeader call警告。✅ 修复后的代码gofunc 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.Errors检查时机c.Next()之前永远空c.Next()之后recover 类型断言err.(error)可能二次 panicswitch安全处理任意类型重复写入风险无保护c.Writer.Written()判断Abort()位置c.Next()前会阻止执行只在 recover 中使用 额外建议如果你的业务代码是通过c.Error(err)收集错误而非直接c.JSON返回建议统一错误码go// 业务 Handler 中 if err ! nil { c.Error(err) // 不直接返回交给中间件统一处理 return // 终止当前 Handler但继续走中间件 }如果你已经在 Handler 里直接c.JSON返回错误了那c.Errors机制就用不上这个中间件里的c.Errors分支可以删掉只保留 recover 即可。需要我帮你改成只处理 panic 的精简版本吗