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 是否都为空。
