不能在中间件里直接启动 goroutine 操作 c.Writer，因为 c.Writer 绑定请求生命周期，handler 返回后底层响应器可能被复用或回收，goroutine 中调用 Write() 或 Status() 会 panic 或返回脏数据；安全做法是替换为自定义 responseWriterWrapper，在 c.Next() 后提取缓存的响应体和状态码，再传参给 goroutine 归档。
为什么不能在中间件里直接启动 goroutine 操作 c.Writer
因为 c.Writer 是绑定到当前 HTTP 请求生命周期的，一旦 handler 返回、响应写出完成，Gin 会复用或回收底层 http.ResponseWriter 实例。此时若在 goroutine 中尝试调用 c.Writer.Write() 或读取 c.Writer.Status()，极大概率 panic（如 write on closed body）或返回错误/脏数据。归档动作必须基于已确定的、可安全拷贝的数据，而非对 writer 的实时引用。
如何安全提取响应内容用于异步归档
需要在中间件中替换 c.Writer 为自定义 wrapper，缓存响应体和状态码，等 c.Next() 执行完毕后再提取——这是唯一能拿到完整响应数据的方式。
- 定义
responseWriterWrapper结构体，内嵌gin.ResponseWriter，并添加*bytes.Buffer和statusCode字段 - 重写
WriteHeader()方法，记录状态码并透传 - 重写
Write()方法，双写：一份进 buffer 缓存，一份透传给原 writer - 在
c.Next()后，从 wrapper 中读取body.Bytes()和statusCode，然后启动 goroutine 归档
示例关键片段：
func archiveMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
writer := &responseWriterWrapper{
ResponseWriter: c.Writer,
body: &bytes.Buffer{},
statusCode: 200, // 默认
}
c.Writer = writer
c.Next() // 执行后续 handler
// 此时响应已发出，但数据还在 buffer 里
go func(status int, body []byte, path string) {
// 归档逻辑：写入文件、发 Kafka、存 ES 等
if err := saveToArchive(path, status, body); err != nil {
log.Printf("archive failed for %s: %v", path, err)
}
}(writer.statusCode, writer.body.Bytes(), c.Request.URL.Path)
}
}
归档 goroutine 中必须避免的三个坑
即使响应内容已提取，异步归档仍容易出错：
- 不要在 goroutine 中访问
c.Request.Header、c.Param()、c.Get("key")等——这些依赖*gin.Context生命周期，handler 返回后不可靠 - 所有需传递的字段（如
c.ClientIP()、c.GetString("user_id")、c.Request.UserAgent()）必须在c.Next()前显式提取并作为参数传入 goroutine - 归档失败不能影响主流程，但必须有日志+错误分类（如网络超时 vs 序列化失败），否则问题会静默丢失
归档内容是否包含响应头？
标准 responseWriterWrapper 只捕获响应体和状态码，不捕获 Header。如果归档需含 Header（如 Content-Type、X-Request-ID），需额外在 wrapper 中维护 map[string][]string 并重写 Header().Set() 和 Header().Add() 方法——但这会显著增加复杂度，且多数归档场景只需 body + status + path + client IP 即可满足审计要求。真要 Header，建议改用访问日志中间件 + 独立 trace ID 关联，而非强求归档响应头。
