在Gin中间件中用io.NopCloser重写c.Request.Body会引发数据泄露吗？

关于资源泄露的顾虑 #

你担心替换c.Request.Body的Close()方法会导致资源泄露，其实这个顾虑是多余的：

• 代码中已经主动调用了c.Request.Body.Close()，原请求体（通常是来自网络连接的io.ReadCloser实例）持有的操作系统资源（如TCP连接读缓冲区）已经被正确释放。
• 后续替换的io.NopCloser(bytes.NewBuffer(bodyBytes))中，bytes.NewBuffer是基于内存的缓冲区，本身不需要任何操作系统资源，io.NopCloser的Close()方法只是空操作，不会有未释放的资源残留。

当前代码的可优化点 #

现有代码存在几个可以提升健壮性的地方：

• 忽略了io.ReadAll和Close()的错误，这些错误可能提示请求体读取失败或资源释放异常，至少应该记录日志。
• 当请求体不是合法JSON时直接跳过日志记录，不利于调试非JSON格式的请求。

更优实现方案 #

下面是优化后的代码，兼顾资源安全、错误处理和调试完整性：

return func(c *gin.Context) {
    // 读取请求体，处理读取错误
    bodyBytes, err := io.ReadAll(c.Request.Body)
    if err != nil {
        logrus.Error("读取请求体失败: ", err)
        c.Next()
        return
    }

    // 关闭原请求体，记录关闭异常
    if err := c.Request.Body.Close(); err != nil {
        logrus.Warn("关闭原请求体失败: ", err)
    }

    // 重新构造可重复读取的请求体
    c.Request.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))

    // 尝试解析JSON，兼容非JSON格式请求
    var bodyContent interface{} = string(bodyBytes)
    var bodyJSON map[string]interface{}
    if err := json.Unmarshal(bodyBytes, &bodyJSON); err == nil {
        bodyContent = bodyJSON
    }

    // 记录调试日志
    logrus.WithFields(logrus.Fields{
        "method": c.Request.Method + "-request",
        "path":   c.Request.URL.Path,
        "query":  c.Request.URL.RawQuery,
        "body":   bodyContent,
    }).Info()

    c.Next()
}

关键说明 #

1. 资源安全：原请求体的Close()已执行，资源已释放；新的请求体基于内存缓冲区，无额外资源需要清理。
2. 错误处理：读取和关闭操作的错误都被捕获并记录，便于排查线上问题。
3. 兼容性：无论请求体是否为JSON，都会记录内容，保证调试信息完整。

内容的提问来源于stack exchange，提问作者Vũ Khoa