Go io.NopCloser 怎样把 Reader 传给需要 ReadCloser 的接口

如果一个 API 要求 io.ReadCloser，但手里只有 strings.Reader、bytes.Reader 或自定义的 io.Reader，可以用 io.NopCloser 做适配：

body := io.NopCloser(strings.NewReader("name=go"))

它补上的 Close 方法什么也不做，适合“调用方需要统一调用 Close，但底层 Reader 没有资源需要释放”的场景。若底层是文件、连接或压缩解码器，不能用它替代真实的关闭动作。

一、先看 Reader 和 ReadCloser 的差别

io.Reader 只约定 Read；io.ReadCloser 在此基础上还要求 Close。Go 的接口是隐式实现的，因此只要补上这一个方法，就能把已有 Reader 传给需要 ReadCloser 的代码。

package main

import (
    "fmt"
    "io"
    "strings"
)

func consume(r io.ReadCloser) error {
    // 统一由调用方负责读取和关闭，便于复用同一套流程。
    defer r.Close()

    data, err := io.ReadAll(r)
    if err != nil {
        return fmt.Errorf("读取输入失败: %w", err)
    }
    fmt.Println(string(data))
    return nil
}

func main() {
    // strings.Reader 只有 Read，没有真实资源需要释放。
    reader := strings.NewReader("hello, nop closer")
    if err := consume(io.NopCloser(reader)); err != nil {
        fmt.Println(err)
    }
}

这里的 defer r.Close() 仍然有价值：consume 不必关心传入的是文件、连接还是无资源 Reader。但 NopCloser 的 Close 是空操作，不能据此推断底层对象已经被清理。

二、最常见的请求体适配

构造 HTTP 请求时，http.NewRequest 的 body 参数类型是 io.Reader，直接传字符串 Reader 就够了。只有当自定义函数或测试夹具明确要求 io.ReadCloser 时，才需要 io.NopCloser。

package main

import (
    "fmt"
    "io"
    "net/http"
    "strings"
)

func requestBody() io.ReadCloser {
    // 请求体来自内存字符串，不持有文件描述符或网络连接。
    return io.NopCloser(strings.NewReader(`{"name":"go"}`))
}

func main() {
    req, err := http.NewRequest(http.MethodPost, "https://example.invalid/api", requestBody())
    if err != nil {
        fmt.Println("创建请求失败:", err)
        return
    }
    // 只展示适配结果；示例不发送网络请求。
    fmt.Println(req.Method, req.Body != nil)
}

如果直接传 strings.NewReader 给 http.NewRequest，标准库可以完成类型适配，并可能推断内容长度。包一层 NopCloser 后，调用方获得的是明确的 io.ReadCloser，但不会自动增加真实的关闭资源。

三、什么时候不能使用 NopCloser

下面这些对象自身拥有需要释放的资源，应该保留原始的 Close，而不是先把它们转换成普通 Reader 再套 NopCloser：

一个实用判断是：问清楚“谁拥有这个资源、谁负责释放它”。NopCloser 只解决接口形状，不转移也不履行底层资源的生命周期责任。

四、读写错误和 Close 返回值怎么处理

io.NopCloser 的 Close 总是返回 nil，所以真正需要判断的是 Read 返回的错误，以及外层流程可能产生的错误。不要因为 Close 没有错误，就忽略读取阶段的失败。

func drain(r io.ReadCloser) error {
    // NopCloser 的 Close 不会报告底层读取错误，读取错误必须在这里处理。
    defer func() {
        _ = r.Close()
    }()

    buf := make([]byte, 8)
    for {
        n, err := r.Read(buf)
        if n > 0 {
            fmt.Printf("读取 %d 字节\\n", n)
        }
        if err == io.EOF {
            return nil
        }
        if err != nil {
            return fmt.Errorf("读取失败: %w", err)
        }
    }
}

如果接口规定必须检查 Close 错误，也可以显式接收返回值；对 NopCloser 来说它会是 nil，但换成真实的 ReadCloser 后，调用约定仍然成立。

五、最小检查清单

1. 只有接口要求 io.ReadCloser 时才包装，普通 io.Reader 不需要多一层。
2. 确认底层只代表内存或无资源输入；文件、连接、解码器必须保留真实的 Close。
3. 把 Close 放在拥有适配值的函数中统一调用，但不要把它当成资源释放证明。
4. 优先检查读取错误；io.NopCloser 的空关闭不会掩盖读取失败。

常见问题

io.NopCloser 会复制 Reader 的数据吗？

不会。它只返回一个带有 Read 和空 Close 的包装值，读取仍然来自原 Reader。

用了 NopCloser 后还需要调用 Close 吗？

如果上层接口约定调用 Close，仍然应该调用。这样代码可以平滑替换成真实的 ReadCloser；只是当前包装的 Close 不负责释放外部资源。

http.NewRequest 的 body 一定要用 NopCloser 吗？

不一定。它本身接收 io.Reader；只有自定义接口、测试代码或生命周期约定要求 io.ReadCloser 时，才使用 NopCloser。

官方资料：https://pkg.go.dev/io#NopCloser