Go 最被低估的设计：两个方法，统一了一切

人们谈论 Go，总是先说 goroutine 和 channel。但真正让 Go 标准库如此简洁一致的，是io包里两个只有一个方法的接口。

同一个模式，四种场景

先看四段代码——

读取文件：

f,_:=os.Open("data.txt")data,_:=io.ReadAll(f)

解析 HTTP 请求体：

varuser User json.NewDecoder(r.Body).Decode(&user)

接收 HTTP 响应：

resp,_:=http.Get("https://api.example.com")body,_:=io.ReadAll(resp.Body)

读取 TCP 连接：

conn,_:=net.Dial("tcp","localhost:9999")data,_:=io.ReadAll(conn)

文件、HTTP Body、TCP 连接——三种完全不同的数据源，同一套读取方式。

这不是巧合。

两个接口，定义了一切数据流

io包的源码里，两个核心接口各只有一个方法：

typeReaderinterface{Read(p[]byte)(nint,errerror)}typeWriterinterface{Write(p[]byte)(nint,errerror)}

没有继承层级，没有泛型约束，没有抽象基类。就是两个方法签名。

但 Go 标准库里，几乎所有跟"读"有关的东西都实现了io.Reader，所有跟"写"有关的东西都实现了io.Writer：

io.Reader ┌──────────┬──────┼──────┬──────────┐ │ │ │ │ │ os.File strings. bytes. net.Conn http. Reader Reader Response. Body io.Writer ┌──────────┬──────┼──────┬──────────┐ │ │ │ │ │ os.File strings. bytes. net.Conn http. Builder Buffer Response. Writer

一旦理解了这两个接口，你就可以写出这样的函数：

funcprocess(r io.Reader,w io.Writer)error{data,_:=io.ReadAll(r)result:=transform(data)_,err:=w.Write(result)returnerr}

这个函数能处理4×4=16 种输入输出组合——文件到文件、网络到内存、字符串到 HTTP 响应、TCP 到 JSON Encoder……不必修改一行代码，因为所有数据源对process来说都是io.Reader，所有数据目标都是io.Writer。

为什么这比别的语言更简洁

Python 靠鸭子类型——任何有read()方法的对象都能"当作文件用"。问题是你没法从类型签名上判断一个参数到底是什么。阅读代码时，你只能靠经验和文档猜测。

JavaScript 有ReadableStream和WritableStream，概念上等价于 Go 的 Reader 和 Writer。但它的 API 要复杂得多——pipeTo、pipeThrough、getReader、controller——方法多意味着心智负担重。

Go 选择了一条不同的路：

• 接口只有一个方法——实现成本极低，任何类型加一个Read([]byte)就融入整个标准库体系
• 隐式实现——不需要写implements Reader，编译器自动识别
• 全标准库遵守——学会一套模式，到处都能用

fmt.Fprintf就是一个好例子。它接受io.Writer作为第一个参数：

fmt.Fprintf(os.Stdout,"hello")// 写到终端fmt.Fprintf(file,"hello")// 写到文件fmt.Fprintf(&buf,"hello")// 写到内存 bufferfmt.Fprintf(httpResponse,"hello")// 写到 HTTP 响应

记住一次，到处使用。

隐式接口：Go 最有争议也最巧妙的设计

Java 程序员写接口，要先定义interface，再声明class X implements Y。实现方必须显式引用调用方定义的接口，产生编译期耦合。

Go 反其道而行：接口由使用方定义，实现方不需要知道接口的存在。

// 实现方：只管写自己的方法typeMyReaderstruct{}func(r MyReader)Read(p[]byte)(int,error){returncopy(p,"hello"),nil}// 使用方：定义自己需要的接口typereaderinterface{Read([]byte)(int,error)}funcconsume(r reader){...}

MyReader的作者根本不知道世界上有一个叫io.Reader的接口——他只是在 struct 上加了一个Read方法。然后这个类型就能被任何接受io.Reader的函数使用。

这种解耦方式有一个优美的实践结果：http.Handler接口只有一个ServeHTTP方法。你定义一个 struct，写一个ServeHTTP方法，不需要 import 任何东西，它就是合法的 HTTP 处理器。框架不认识你，但你满足它的接口，它就接受你。

这就是“Don’t design with interfaces, discover them”的含义——不为未来的抽象写接口，在真正需要多态的地方才定义接口。

标准库即接口教材

换个角度看 Go 标准库——六个包，六个领域，同一套接口哲学：

标准库不是 API 参考手册，是一本接口设计教材。学完一个包的接口风格，下一个包的 API 你大概能猜到——好的设计会传染。

几点建议

先啃下io.Reader和io.Writer，再学其他。它们是 Go 标准库的"元接口"。理解了它们，后面学os、json、http、bufio都会有"果然如此"的感觉——不是在记新 API，而是在看同一个模式的不同应用。

写代码时故意换数据源。同一个处理函数，先用文件测，再用字符串测，再用 HTTP Body 测。反复验证"接口不关心具体类型"，直到它变成本能。

别抱怨 Go 没有泛型方法、没有继承、没有 try-catch。当一段三百行的代码里，反复出现的模式只有两个接口时，你会意识到——少不是缺失，是刻意。

两个方法，一个理念。Go 的简洁不是简陋，是把正确的事情做对，然后到此为止。