如何在 Go 中正确判断接口类型变量是否为 nil

Go 中接口变量为 nil 的条件是其底层类型和值均为 nil；若仅值为 nil 而类型已确定（如 *bytes.Reader），则接口本身非 nil，但调用其方法会触发 panic。需通过类型断言或反射安全检查，或更推荐——避免将未初始化的指针直接赋给接口参数。

Go 中接口变量为 nil 的条件是其底层类型和值均为 nil；若仅值为 nil 而类型已确定（如 *bytes.Reader），则接口本身非 nil，但调用其方法会触发 panic。需通过类型断言或反射安全检查，或更推荐——避免将未初始化的指针直接赋给接口参数。

在 Go 中，http.NewRequest 的第三个参数类型为 io.Reader，这是一个接口。你遇到的 panic 并非因为传入了 nil，而是因为传入了一个类型明确但值为 nil 的接口实例——这正是 Go 接口 nil 判断中最易混淆的关键点。

? 为什么 content = nil 后仍 panic？

看这段代码：

var content *bytes.Reader
content = nil
req, _ := http.NewRequest("GET", "http://www.github.com", content)

虽然 content 是 nil，但将其作为 io.Reader 传入时，Go 会隐式转换为接口 io.Reader。此时接口内部存储的是：

• 类型： *bytes.Reader
• 值： nil

而 Go 规定：只有当接口的类型和值同时为 nil 时，该接口才为 nil。此处类型非空，因此 io.Reader(content) 不是 nil 接口。http.NewRequest 内部尝试调用 content.Read(...) 时，实际是在 nil *bytes.Reader 上调用方法，导致 panic。

✅ 正确做法是直接传 nil（无类型信息的字面量）：

req, err := http.NewRequest("GET", "http://www.github.com", nil) // ✅ 类型和值均为 nil

此时 nil 被赋予 io.Reader 接口，Go 推导出接口的类型为 nil、值也为 nil，因此整个接口为 nil，NewRequest 内部会跳过读取逻辑（GET 请求通常无 body）。

✅ 安全检查接口是否真正可读（进阶）

若你无法确保传入的是裸 nil，而必须处理可能含 nil 值的接口（如 io.Reader），可通过类型断言+空值检查来防御：

func isNilReader(r io.Reader) bool {
    if r == nil {
        return true // 真正的 nil 接口
    }
    // 检查是否为具体类型的 nil 指针
    switch v := r.(type) {
    case *bytes.Reader:
        return v == nil
    case *strings.Reader:
        return v == nil
    case *bytes.Buffer:
        return v == nil
    default:
        return false // 其他类型暂不深究，按非-nil 处理
    }
}

但注意：这种检查不能通用化到所有接口，且违背了接口抽象的设计初衷。最佳实践仍是：不要构造“带类型但值为 nil”的接口，优先使用裸 nil 或明确初始化的 reader。

? 常见错误与建议

• ❌ 错误：var r *bytes.Reader; r = nil; req, _ := http.NewRequest(..., r)
• ✅ 正确：req, _ := http.NewRequest(..., nil) 或 req, _ := http.NewRequest(..., bytes.NewReader([]byte{}))
• ⚠️ 注意：http.NewRequest 对 nil body 有特殊处理（设置 req.Body = nil），无需额外判断；但自定义逻辑中若需调用 r.Read()，务必先确认 r != nil 且非“伪 nil 接口”。

总之，理解 Go 接口的双元组（type + value）本质，是避免此类 panic 的根本。永远记住：nil 是字面量，不是类型；接口是否为 nil，取决于它内部存储的 type 和 value 是否都为空。