Go语言中http.Request的Body为何被设计为interface类型

http.Request的Body字段声明为io.ReadCloser接口类型，是Go语言小接口设计哲学的典型实践，核心原因如下：

• 适配多场景的灵活扩展
  HTTP请求体的底层来源非常多样：生产环境下是TCP连接传输的网络流，单元测试场景下可以是本地构造的字符串、字节数组，中间件链路中还可能是被包装过的加密流、压缩流、日志采集流。使用接口类型后，只要底层实现满足「可读、可关闭」的约定，就可以赋值给Body字段，不需要修改HTTP标准库的核心逻辑，上层使用也完全不需要感知底层差异。
  比如单元测试时，可以非常方便地构造测试请求体：

req, _ := http.NewRequest(http.MethodPost, "/your/api", nil)
// 直接用字符串构造测试用Body，无需依赖真实网络
req.Body = io.NopCloser(strings.NewReader("test payload"))

• 统一操作约定，降低使用成本
  接口只约束了两个核心方法：Read(p []byte) (n int, err error)用来读取请求体内容，Close() error用来释放底层资源（比如回收TCP连接、释放缓冲区）。所有上层使用者只需要记住「读完关Body」的通用约定即可，不需要为不同来源的请求体学习不同的API。
  同时标准库的开发方也可以自由迭代优化Body的底层实现，只要不违反io.ReadCloser的方法约定，就不会影响已有业务代码的兼容性。
• 符合Go小接口的组合设计思想
  io.ReadCloser本身是io.Reader和io.Closer两个最小粒度接口的组合，你可以很方便地对原有Body做能力增强，比如要给请求体做自动gzip解压，只需要做一层轻量包装即可，不需要修改原有HTTP处理逻辑：

type gzipBody struct {
    reader io.Reader
    origin io.ReadCloser
}
func (g *gzipBody) Read(p []byte) (n int, err error) {
    return g.reader.Read(p)
}
func (g *gzipBody) Close() error {
    return g.origin.Close()
}
// 中间件中替换原Body为带解压能力的实现
newBody, _ := gzip.NewReader(req.Body)
req.Body = &gzipBody{reader: newBody, origin: req.Body}

内容的提问来源于stack exchange，提问作者白觐瑄