Go 接口：从行为契约到运行时类型

很多人第一次看到接口，会把它理解成“没有字段的抽象类”。这个类比只能帮你走两步，再往前就容易误判。Go 的接口更像一份由调用方提出的行为契约：函数只声明自己需要哪些能力，任何类型只要恰好提供这些方法，就能参与协作，不需要登记“我实现了谁”。

这套机制把两个问题分开了：具体类型负责“数据怎么存、事情怎么做”，接口负责“调用方最低需要什么”。理解这条分界线之后，io.Writer 为什么能同时代表文件、缓冲区和网络连接，http.HandlerFunc 为什么能把普通函数接入 Web 服务器，以及 error 为什么可以携带结构化信息，都会变得自然。

本文会沿着一条完整路径展开：先看契约与隐式满足，再拆开方法集和接口值，处理 nil 与比较的陷阱，然后进入排序、HTTP、错误、表达式树、类型断言、类型开关和 XML 流式解析。最后我们会补上泛型出现后的类型集边界，并把接口设计收束成可以直接用于工程评审的规则。

接口是一份由调用方提出的契约

具体类型把表示和操作绑在一起。拿到 *os.File，我们知道值里是一个文件对象，也知道可以读取、写入、关闭。接口则故意隐藏表示，只承诺一小组方法。拿到 io.Writer 时，我们不知道背后是文件、内存缓冲区、哈希器还是 HTTP 响应，但可以确定一件事：能够调用 Write。

type Writer interface {
	Write(p []byte) (n int, err error)
}

契约是双向的。调用方承诺只依赖 Write 以及它的行为约定；实现方承诺按约定处理字节、返回写入数量，并在短写时给出非 nil 错误。方法签名相同只是类型层面的门槛，行为是否正确仍由实现者负责。

fmt.Fprintf 正是这种分工的代表。它负责格式化，却不决定结果去哪里：

package main
 
import (
	"bytes"
	"fmt"
	"io"
)
 
type ByteCounter int
 
func (c *ByteCounter) Write(p []byte) (int, error) {
	*c += ByteCounter(len(p))
	return

同一个 writeGreeting 没有分支判断，也不需要知道 bytes.Buffer 和 ByteCounter 的内部结构。实现可以替换，调用逻辑不变，这就是接口带来的可替换性。

为什么接口通常放在使用方

如果某个报表服务只需要保存文本，那么它可以在自己的包里定义最小接口：

type Saver interface {
	Save(text string) error
}
 
func BuildReport(dst Saver) error {
	return dst.Save("今日报告")
}

数据库实现、文件实现和测试替身都不必导入这个包来显式声明关系。只要方法吻合，编译器就会接受。接口放在使用方还有一个现实好处：需求由使用者决定。若调用方只需要 Save，就不要迫使所有实现再提供 Load、Delete 和 List。

本节练习

实现一个 LineCounter，让它满足 io.Writer：每次写入时累计字节切片中的换行符数量，并返回 len(p), nil。

type LineCounter int
 
func (c *LineCounter) Write(p []byte) (int, error) {
	for _, b := range p {
		if b == '\n' {
			*c += 1
		}
	}
	return len(p), nil
}

标准接口是一套可以复用的能力词汇

在拆运行时细节之前，我们先看接口在真实 API 中怎样落地。Go 标准库里最有价值的接口，往往只有一个或几个方法。它们像一组稳定的能力词汇，让独立包之间可以协作。后面的排序与 HTTP 会把这种设计放大，再回到语言规则解释它为什么成立。

单方法接口通常按方法加 -er 的习惯命名，例如 Reader、Writer、Closer。命名不是纯粹的风格问题：一旦选择了 Write、Close、String 这类通用名称，最好沿用标准签名和语义，减少“方法碰巧同名、行为却完全不同”的意外满足。

fmt.Stringer 控制展示，不承担序列化

type Temperature float64
 
func (t Temperature) String() string {
	return fmt.Sprintf("%.1f°C", t)
}
 
fmt.Println(Temperature(23.5)) // 23.5°C

String 适合给日志和界面提供人类可读形式。若文本还要稳定地被程序解析、持久化或跨版本传输，应使用明确的编码协议，不要把 String 当成通用序列化格式。另一个常见坑是在 String 内对接收者再次调用会触发 String 的格式化，从而无限递归；必要时先转换为底层类型。

flag.Value 把解析和展示配成一对

自定义命令行参数只需实现 String 与 Set。下面让 -level 接受 debug、info 或 error：

package main
 
import (
	"flag"
	"fmt"
	"strings"
)
 
type Level string
 
func (l *Level) String() string {
	if l == nil {
		return ""
	}
	return string(*l)

Set 把字符串写入值，String 则把当前值用于帮助信息和诊断。二者使用同一套表示，用户看到的默认值才能原样作为输入。由于 Set 要修改值，这里由 *Level 满足接口。

行为查询让优化保持可选

有时基础接口够用，但某些实现还提供更高效的附加能力。io.WriteString 的思路可以简化成：先询问 io.Writer 的动态类型是否还支持 WriteString，支持就走快路径，否则回退到 Write([]byte(s))。

type stringWriter interface {
	WriteString(string) (int, error)
}
 
func writeString(w io.Writer, s string) (int, error) {
	if sw, ok := w.(stringWriter); ok {
		return sw.WriteString(s)
	}
	return w.Write

这叫行为查询：检查的是“还会不会某种行为”，而不是“到底是哪种结构体”。它让扩展能力保持可选，也让未知的新实现仍能走正确的基础路径。

本节练习

给前面的 Level 增加 Get() any，使它同时满足 flag.Getter。为什么 Getter 是在 Value 之上扩展，而没有直接修改 Value？

func (l *Level) Get() any {
	return Level(*l)
}
 
var _ flag.Value = (*Level)(nil)
var _ flag.Getter = (*Level)(nil)

用 sort.Interface 把算法与数据表示分开

经典的 sort.Sort 不知道序列是切片、数组视图还是别的结构，也不知道元素长什么样。它只要求三种能力：长度、比较两个位置、交换两个位置。

type Interface interface {
	Len() int
	Less(i, j int) bool
	Swap(i, j int)
}

假设我们要按分数降序、姓名升序排列学生：

package main
 
import (
	"fmt"
	"sort"
)
 
type Student struct {
	Name  string
	Score int
}
 
type ranking []Student
 
func (r ranking) Len() int      { return len(r) }
func (r 

这里 ranking 决定数据表示和次序，sort.Sort 复用成熟算法。sort.Reverse 更能说明接口组合的力量：它包装原接口，只反转 Less 的参数顺序，Len 与 Swap 仍交给原值。

sort.Sort(sort.Reverse(students))

Less 必须形成一致的严格次序。若比较结果自相矛盾，例如同一对元素有时返回不同结果，排序结果就不可靠。稳定排序还保证比较等价的元素保持原有相对次序，可以使用 sort.Stable。

现代切片排序更直接

今天如果数据就是切片，泛型 slices.Sort 和 slices.SortFunc 往往更简洁，也能省掉 Len、Swap 的样板代码：

slices.SortFunc(students, func(a, b Student) int {
	if a.Score != b.Score {
		return cmp.Compare(b.Score, a.Score)
	}
	return cmp.Compare(a.Name, b.Name)
})

这并不让 sort.Interface 失去意义。它仍展示了如何把算法所需的最小操作抽成契约，也适合不是普通切片的数据结构或需要接入既有 API 的场景。

本节练习

实现 IsPalindrome(data sort.Interface) bool。约定当 !Less(i,j) && !Less(j,i) 时，两个位置相等。

func IsPalindrome(data sort.Interface) bool {
	for i, j := 0, data.Len()-1; i < j; i, j = i+1, j-1 {
		if data.Less(i, j) || data.Less(j, i) {
			return false
		}
	}
	return

http.Handler 把函数、对象与中间件接到同一条管线

HTTP 服务器的核心契约只有一个方法：

type Handler interface {
	ServeHTTP(ResponseWriter, *Request)
}

任何类型只要实现 ServeHTTP，就能交给服务器或路由器。一个 map 类型也可以直接成为处理器：

type Prices map[string]float64
 
func (p Prices) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	item := r.URL.Query().Get("item")
	price, ok := p[item]
	if !ok {
		http.Error(w, 

普通函数没有方法，因此不能直接满足 Handler。标准库提供命名函数类型 http.HandlerFunc，并为它实现 ServeHTTP：方法内部只是调用函数本身。

func health(w http.ResponseWriter, r *http.Request) {
	w.WriteHeader(http.StatusNoContent)
}
 
var h http.Handler = http.HandlerFunc(health)

这是适配器模式的一个紧凑版本：给函数类型加方法，把已有函数适配到接口。ServeMux.HandleFunc 进一步隐藏了显式转换。

中间件也是 Handler 到 Handler 的变换

func logRequests(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		log.Printf("%s %s", r.Method, r.URL.Path)
		next.ServeHTTP(w, r)
	})
}
 
func

路由器是 Handler，中间件接收并返回 Handler，服务器也接收 Handler。这条闭环让鉴权、日志、限流和恢复逻辑可以一层层包装，而业务处理器不需要知道外层结构。

ResponseWriter 只能在 ServeHTTP 返回前安全使用；处理器也可能被多个 goroutine 并发调用，共享 map 或计数器时必须同步。另一个 HTTP 细节是：状态码要在写响应体之前设置，因为首次 Write 通常会隐式发送成功响应头。

本节练习

写一个恢复 panic 的中间件：若下游处理器 panic，返回 500；正常时保持原行为。生产代码还应记录堆栈。

func recoverPanic(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		defer func() {
			if v := recover(); v != nil {
				http.Error(w, "服务器内部错误"

接口声明、嵌入与隐式满足

前面已经看到小接口怎样连接格式化、排序和 HTTP。现在把镜头拉回语言本身：接口声明列出方法。方法的顺序不影响类型，名字和完整签名才重要：

type Reader interface {
	Read(p []byte) (n int, err error)
}
 
type Writer interface {
	Write(p []byte) (n int, err error)
}
 
type ReadWriter interface {
	Reader
	Writer
}

把 Reader、Writer 嵌入 ReadWriter，相当于把两个方法展开写入。这里是接口组合，不是类继承，也没有父子对象。任何同时拥有 Read 和 Write 的类型都会自动满足 ReadWriter。

“自动”并不代表编译器会放宽匹配。方法名、参数类型、参数顺序和返回值都必须一致。下面的 Read([]byte) error 少了读取数量，不能满足 io.Reader；Read(string) (int, error) 参数不同，也不行。Go 不做方法重载或近似匹配。

type MemoryStore struct {
	data []byte
}
 
func (m *MemoryStore) Read(p []byte) (int, error) {
	return copy(p, m.data), nil
}
 
func (m *MemoryStore) Write(p []byte) (int, error

最后三行是常见的编译期断言。右侧的类型化 nil 不会分配对象，目的只是请编译器检查方法集。以后有人改坏签名，错误会在实现附近出现，而不是等到很远的调用处才暴露。

本节练习

把下面的显式重复声明改成嵌入形式：

type ReadWriteCloser interface {
	Read([]byte) (int, error)
	Write([]byte) (int, error)
	Close() error
}

type ReadWriteCloser interface {
	Reader
	Writer
	Closer
}

方法集决定 T 与 *T 谁能满足接口

接口满足看的是类型的方法集，而不是“某次调用能不能写出来”。对命名类型 T，可以先记住最实用的规则：

• T 的方法集包含接收者为 T 的方法。
• *T 的方法集包含接收者为 T 和 *T 的方法。

type Counter struct {
	n int
}
 
func (c Counter) String() string { // 值接收者
	return fmt.Sprintf("%d", c.n)
}
 
func (c *Counter) Add(delta int) { // 指针接收者
	c.n += delta
}

你可能见过 var c Counter; c.Add(1) 能正常编译。那是因为 c 可寻址，编译器把调用改写成 (&c).Add(1)。这种调用语法糖没有把 Add 加进 Counter 的方法集，所以 Counter{} 仍不能赋给 Adder。

值接收者通常适合小型、不可变语义的值；指针接收者适合修改接收者、避免复制大对象，或保持一组方法的接收者形式一致。接口不是选择接收者的唯一依据，但方法集会直接决定可赋值范围。

本节练习

写两条编译期断言，证明 bytes.Buffer 的指针满足 io.Writer，而值不满足。为什么？

var _ io.Writer = (*bytes.Buffer)(nil)
// var _ io.Writer = bytes.Buffer{} // 编译错误

接口值装着动态类型与动态值

接口变量本身有固定的静态类型，同时在运行时携带一对信息：动态类型和动态值。可以把它想成一个带标签的盒子，但要知道这只是理解模型，不是对内存布局的承诺。

var w io.Writer         // 静态类型始终是 io.Writer
w = os.Stdout           // 动态类型 *os.File，动态值是标准输出指针
w = new(bytes.Buffer)   // 动态类型 *bytes.Buffer，动态值是缓冲区指针
w = nil                 // 动态类型、动态值都为空

通过 w.Write 调用方法时，运行时根据动态类型找到对应实现，并把动态值交给它当接收者。这叫动态派发。w 的静态类型仍然是 io.Writer，所以即使动态值是 *os.File，也不能直接写 w.Close()；Close 没有出现在 io.Writer 的方法集中。

接口赋给另一个接口时，不会形成“盒子套盒子”。例如把 io.ReadWriter 赋给 io.Writer，目标接口仍然保存原来的具体动态类型与动态值，只是静态可见的方法变少了。

fmt.Printf("%T", w) 可以观察动态类型；%v 会按格式化规则展示动态值。调试接口问题时，常把两者和 w == nil 一起打印：

fmt.Printf("type=%T value=%v nil=%t\n", w, w, w == nil)

静态类型限制调用，动态类型选择实现

这两个层次不要混在一起：编译器先按静态类型检查“能不能调用”；程序运行后，再按动态类型决定“调用哪个实现”。类型断言正是从静态接口视角临时获取更多信息的操作，后文会继续使用这套模型。

本节练习

下面代码能否通过编译？若不能，应怎样获得 Close 能力？

var w io.Writer = os.Stdout
_ = w.Close()

if wc, ok := w.(io.WriteCloser); ok {
	_ = wc.Close()
}

nil 接口、nil 指针与比较边界

一个接口值只有在动态类型和动态值都为空时才等于 nil：

var w io.Writer
fmt.Println(w == nil) // true

把类型化的 nil 指针装进接口后，情况变了：

var buf *bytes.Buffer = nil
var w io.Writer = buf
 
fmt.Println(buf == nil) // true
fmt.Println(w == nil)   // false
fmt.Printf("%T\n", w)  // *bytes.Buffer

此时接口的动态类型是 *bytes.Buffer，动态值才是 nil，所以整个接口不为 nil。调用 w.Write 会派发到 (*bytes.Buffer).Write，该实现无法接受空接收者，于是 panic。并非所有 nil 指针接收者调用都必然 panic；方法可以主动处理 nil。真正的问题是：接口的 nil 检查只看整对信息，不能代替具体实现的前置条件。

最稳妥的修正通常发生在赋值之前。若“不开启输出”就应该传入 nil 接口，让变量从一开始就是接口类型：

var out io.Writer
if debug {
	out = new(bytes.Buffer)
}
writeResult(out)
 
func writeResult(out io.Writer) {
	if out == nil {
		return
	}
	_, _ = out.Write([]byte("done\n

接口比较为什么可能 panic

接口类型可以出现在 ==、!=、switch 和 map 键位置，但安全性取决于动态类型。两个接口都为 nil 时相等；否则只有动态类型相同且动态值相等才相等。若比较过程中遇到不可比较的动态类型，如切片、map 或函数，就会在运行时 panic。

var a any = []int{1, 2, 3}
var b any = []int{1, 2, 3}
fmt.Println(a == b) // panic: comparing uncomparable type []int

不同动态类型时无需比较动态值，因此 any([]int{1}) == any("x") 会得到 false，不会 panic。问题出现在相同的不可比较动态类型需要继续比较时。包含接口字段的结构体、接口数组和以接口为键的 map 也会把这个风险带进去。

本节练习

解释下面函数为什么可能返回一个“看起来不是 nil”的错误，并给出修正。

type ParseError struct{ msg string }
func (e *ParseError) Error() string { return e.msg }
 
func parse(ok bool) error {
	var err *ParseError
	if !ok {
		err = &ParseError{"格式错误"}
	}
	return

func parse(ok bool) error {
	if !ok {
		return &ParseError{"格式错误"}
	}
	return nil
}

error 是接口，错误值可以携带结构

预声明的 error 只要求一个方法：

type error interface {
	Error() string
}

这意味着错误不只是字符串。Error 给人看，具体错误类型的字段则可以给程序判断。最简单的错误可以用 errors.New 或 fmt.Errorf 创建；需要额外信息时，定义结构化类型：

type ValidationError struct {
	Field string
	Value string
	Why   string
}
 
func (e *ValidationError) Error() string {
	return fmt.Sprintf("字段 %s 的值 %q 无效：%s", e.Field, e.Value, e.Why)
}

调用方如果只想向上返回或记录，可以把它当普通 error；若要把错误定位到表单字段，可以读取 Field。不要通过搜索 Error() 文本来做业务分支，因为措辞、语言和系统底层消息都可能变化。

包装、errors.Is 与 errors.As

现代 Go 错误通常形成一条或一棵错误链。fmt.Errorf 使用 %w 在增加上下文的同时保留底层错误：

func loadConfig(path string) error {
	_, err := os.ReadFile(path)
	if err != nil {
		return fmt.Errorf("读取配置 %q: %w", path, err)
	}
	return nil
}

errors.Is 判断链中是否存在目标错误或等价错误，errors.As 找到链中第一个能赋给目标类型的错误。前者适合哨兵语义，后者适合提取结构：

err := loadConfig("missing.json")
 
if errors.Is(err, fs.ErrNotExist) {
	fmt.Println("配置不存在")
}
 
var pathErr *os.PathError
if errors.As(err, &pathErr) {
	fmt.Println("失败路径：", pathErr.Path)
}

直接写 err.(*os.PathError) 只检查最外层动态类型，而且失败会 panic；errors.As 会沿包装链查找。若你的错误类型包装了另一个错误，实现 Unwrap() error，标准工具就能继续遍历。

func (e *QueryError) Unwrap() error { return e.Err }

本节练习

定义 QueryError，保存查询文本和底层错误，使 errors.Is(queryErr, context.DeadlineExceeded) 能成立。

type QueryError struct {
	Query string
	Err   error
}
 
func (e *QueryError) Error() string {
	return fmt.Sprintf("执行查询 %q: %v", e.Query, e.Err)
}
 
func (e *QueryError) Unwrap() error {
	return

用接口组织表达式树

接口不仅能连接包，也适合表示“一组形态不同、行为相同”的节点。一个算术表达式可能是字面量、变量、一元运算或二元运算。它们内部字段完全不同，但都能在环境中求值，也都能做静态检查。

package main
 
import (
	"fmt"
	"strings"
)
 
type Env map[string]float64
 
type Expr interface {
	Eval(Env) float64
	Check(vars map[string]bool) error
}
 
type Literal

调用方只持有 Expr，递归结构里的每个位置都可以放任意节点。新增节点类型时，需要完整实现 Eval 和 Check；已有递归算法通过接口派发到对应实现，不需要集中维护一条巨大的类型分支。

先检查一次，再求值很多次

Check 负责无需实际输入就能发现的问题：运算符是否合法、函数名是否存在、参数数量是否正确，并收集表达式引用的变量。Eval 则假设结构已通过检查，专注高频计算。

如果一个表达式要在不同环境里执行数万次，把静态错误检查从求值路径移走能减少重复工作。接口在这里表达的不是“节点长得一样”，而是“每种节点都参加同一套生命周期”。

本节练习

新增 Min 节点，保存若干操作数，求其中最小值；空参数在 Check 阶段报错。

type Min struct{ Args []Expr }
 
func (m Min) Eval(env Env) float64 {
	best := m.Args[0].Eval(env)
	for _, arg := range m.Args[1:] {
		if v := arg.Eval(env); v < best {
			best = v

类型断言安全地取回具体值或更多能力

类型断言写作 x.(T)，其中 x 必须是接口表达式。它有两种不同用途。

当 T 是具体类型时，断言检查接口的动态类型是否与 T 完全相同；成功后取出动态值：

var w io.Writer = os.Stdout
file := w.(*os.File) // 成功，file 的类型是 *os.File

os.File 与 *os.File 是不同类型，别忘了指针。若动态类型不匹配，单返回值形式会 panic。外部输入或开放扩展点通常应使用“逗号 ok”形式：

file, ok := w.(*os.File)
if !ok {
	// w 不是 *os.File，file 是 *os.File 的零值 nil
}

当 T 是接口类型时，断言检查当前动态类型是否也满足新接口。动态类型和值不变，只是静态视角获得了不同的方法集：

if rw, ok := w.(io.ReadWriter); ok {
	buf := make([]byte, 8)
	_, _ = rw.Read(buf)
}

对 nil 接口做任何类型断言都会失败。两返回值形式返回目标类型零值和 false；单返回值形式 panic。

何时断言具体类型，何时查询接口

如果逻辑确实依赖某个结构化错误字段，断言具体类型合理。若只是想利用“可刷新”“可写字符串”“可关闭”等能力，优先断言一个就地定义的小接口。前者识别身份，后者询问行为。

type flusher interface {
	Flush() error
}
 
if f, ok := w.(flusher); ok {
	if err := f.Flush(); err != nil {
		return err
	}
}

本节练习

补全 flushIfPossible：普通 bytes.Buffer 不需要刷新，带 Flush() error 的写入器则执行刷新。

func flushIfPossible(w io.Writer) error {
	type flusher interface {
		Flush() error
	}
	if f, ok := w.(flusher); ok {
		return f.Flush()
	}
	return nil
}

类型开关处理一组已知动态类型

连续做多次类型断言时，类型开关更清楚：

func describe(x any) string {
	switch v := x.(type) {
	case nil:
		return "空接口"
	case bool:
		return fmt.Sprintf("布尔值 %t", v)
	case int:
		return fmt.Sprintf("整数 %d", v)
	case string

x.(type) 只能出现在类型开关中。单一类型的 case 里，v 的静态类型就是该 case 类型；case int, int64: 这种多类型分支里，v 保持开关表达式的接口类型，因为编译器无法选出唯一具体类型。类型 case 如果是接口，可能与多个分支重叠，因此更具体的分支通常放在前面。类型开关不允许 fallthrough。

接口在这里有两种使用风格。io.Writer 风格关注共同方法，调用方尽量不看具体类型；any 加类型开关则把接口当作有限候选类型的容器，逻辑明确区分每种类型。第二种风格适合解析器 token、配置值和协议边界，但如果候选类型持续增长，集中式开关会越来越难维护，此时可以考虑把行为移回各具体类型的方法。

本节练习

写一个 quoteSQLArg，只接受 nil、整数、布尔和字符串。这里仅练习类型开关；真实程序必须使用数据库驱动的参数绑定，不要自行拼接 SQL。

func quoteSQLArg(x any) (string, error) {
	switch v := x.(type) {
	case nil:
		return "NULL", nil
	case int:
		return strconv.Itoa(v), nil
	case bool:
		if v { return "TRUE", nil }
		return

XML token 流展示类型开关的合适边界

encoding/xml.Decoder.Token 每次返回一个 xml.Token。当前标准库把 Token 定义为 any，动态值可能是 xml.StartElement、xml.EndElement、xml.CharData、xml.Comment、xml.ProcInst 或 xml.Directive。调用方本来就要针对 token 种类采取不同动作，类型开关正合适。

下面的程序单遍扫描 XML，维护当前元素路径，并输出所有非空文本：

package main
 
import (
	"encoding/xml"
	"fmt"
	"io"
	"strings"
)
 
func main() {
	input := `<catalog><book id="7"><title>Go 接口</title></book></catalog>`
	dec := xml.NewDecoder(strings.NewReader(input))
	var stack []string
 
	for {
		tok, err := dec.

开始标签入栈，结束标签出栈，文本 token 使用当前栈得到路径。整个过程不需要把文档构造成完整树，适合大文件和流式输入。若要把 token 保存到下一次 Token 调用之后，使用 xml.CopyToken 复制，因为某些 token 的字节数据可能被解码器后续复用。

这也是“共同方法接口”和“类型候选容器”的区别：io.Reader 希望调用方忽略具体实现，只调用 Read；xml.Token 则有意暴露有限的 token 种类，让调用方逐类处理。

本节练习

修改示例，只输出位于 catalog/book/title 路径下的文本。

case xml.CharData:
	if strings.Join(stack, "/") != "catalog/book/title" {
		continue
	}
	text := strings.TrimSpace(string(tok))
	if text != "" {
		fmt.Println(text)
	}

any、类型集与泛型约束的边界

any 是 interface{} 的别名。它没有方法要求，因此任何非接口具体类型的值都能装入。得到 any 后，调用方几乎没有静态能力，只能原样传递、格式化、反射，或用断言和类型开关取回信息。

var x any
x = 42
x = "Go"
x = []int{1, 2, 3}

从 Go 1.18 起，规范用“类型集”统一描述接口。只列方法的基本接口，其类型集是所有实现这些方法的非接口类型，可以用于运行时变量。接口嵌入取类型集的交集：同时满足所有方法要求的类型才在结果中。

泛型约束还能写类型项：

type Number interface {
	~int | ~int64 | ~float64
}
 
func Sum[T Number](values []T) T {
	var total T
	for _, v := range values {
		total += v
	}
	return total
}

~int 表示底层类型为 int 的所有命名或未命名类型，| 表示类型集合并。这类非基本接口只能用作约束或嵌入其他约束，不能声明运行时变量：

// var n Number // 编译错误：Number 不是基本接口，不能作为值类型

comparable 不是“绝对不会 panic”的接口盒子

comparable 表示支持 == 和 != 的类型集合，只能用于约束。普通的运行时接口值本身可以写 ==，但当动态值是切片、map 或函数时仍可能 panic。

还有一层容易忽略的边界：从 Go 1.20 起，像 any 这样的可比较接口类型可以满足 comparable 约束，但泛型函数内部的比较仍可能因为实际动态值不可比较而 panic。

func Equal[T comparable](a, b T) bool {
	return a == b
}
 
var a any = []int{1}
fmt.Println(Equal[any](a, a)) // 编译通过，运行时 panic

所以“类型参数受 comparable 约束”和“接口动态值比较绝对安全”不是同一结论。若值由外部输入且可能携带切片等类型，应调整数据模型，或在明确边界使用反射能力进行检查，而不是盲目比较。

本节练习

解释为什么下面两段代码用途不同，并指出哪一段会编译失败。

type Printable interface { String() string }
type Integer interface { ~int | ~int64 }
 
var p Printable
var i Integer

func Twice[T Integer](v T) T { return v + v }

设计接口时只索取当前需要的能力

接口不是越早抽象越好。若一个包里只有一个实现、调用方没有替换需求、包依赖也不需要隔离，直接使用具体类型通常更清楚。先写具体代码，等出现第二个实现或真实边界，再从调用方实际使用的方法中提取接口，往往能得到更小、更稳定的契约。

工程评审时可以按下面的顺序检查：

1. 这个接口解决了哪个替换、隔离或测试边界？若说不清，先考虑具体类型。
2. 每个方法是否都被当前调用方使用？没有使用的方法应从契约移走。
3. 接口是否定义在使用方附近？实现方不应预测所有消费者的抽象。
4. 方法名和签名是否沿用标准语义？同名异义会造成意外满足。
5. 接收者选择是否让预期的 T 或 *T 满足接口？用编译期断言固定意图。
6. 是否把类型化 nil 指针作为成功结果返回到接口？错误和可选依赖尤其要检查。
7. 是否比较了动态类型不受控制的接口值，或把它们用作 map 键？确认动态类型可比较。
8. 类型断言是在询问必要行为，还是把调用方重新绑回具体实现？

“接收接口，返回具体类型”是一条有用的默认启发：参数只索取必要能力，构造函数返回具体值让调用方保留完整能力。但它不是不可破的规则。若返回接口是稳定 API 边界、需要隐藏实现，或多种实现确实可互换，返回接口也合理。判断标准始终是依赖方向和真实替换需求。

本节练习

下面接口由某个用户服务的实现包提前定义。调用方只用 Find，该怎样收缩？

type UserService interface {
	Find(id int64) (User, error)
	Create(User) error
	Delete(id int64) error
	List() ([]User, error)
}

type UserFinder interface {
	Find(id int64) (User, error)
}
 
func RenderProfile(users UserFinder, id int64) error {
	user, err := users.Find(id)
	// ...
	return err
}

综合练习：实现可测试的事件输出管线

我们用一个小任务把本章关键点串起来。目标是实现 Publish：把事件格式化后写入目标；若目标额外支持 Flush() error，写完后刷新；错误要带上阶段上下文并保留错误链。

type Event struct {
	Name string
	Data any
}
 
func Publish(dst io.Writer, e Event) error {
	// 请完成
}

要求：

• dst == nil 时返回明确错误，不制造类型化 nil。
• 使用 fmt.Fprintf 写出 事件=<名称> 数据=<值>\n。
• 写入失败时用 %w 包装。
• 用小接口查询 Flush，不要断言某个具体缓冲类型。
• 刷新失败时同样包装并返回。

func Publish(dst io.Writer, e Event) error {
	if dst == nil {
		return errors.New("事件输出目标为空")
	}
	if _, err := fmt.Fprintf(dst, "事件=%s 数据=%v\n", e.Name, e.Data); err != nil {
		return fmt.Errorf

接口真正解决的不是“把所有类型变成同一种东西”，而是让调用方用最少的行为要求与多种实现合作。写接口时盯住方法集，传接口时盯住动态类型和值，做断言时优先问行为，做比较时确认动态值可比较，再把泛型约束与运行时接口分开。做到这些，接口会成为清晰的边界，而不是隐藏问题的盒子。

关键不是把数据保存下来，而是履行 Writer 契约。若返回的 n 小于 len(p)，还应返回非 nil 错误；这里全部“接收”后丢弃，因此返回完整长度。

这个函数只读取 Len 和 Less，不调用 Swap。接口允许调用方提供更多能力，但函数仍应只使用自己真正需要的部分；若这是新 API，也可以定义只有 Len、Less 的更小接口。

真实服务要留意：如果下游已经写出响应头或部分响应体，再调用 http.Error 已无法完整改写响应。严格实现通常会先用包装的 ResponseWriter 缓冲，或者至少记录这一限制。

Unwrap 建立了错误链；Error 负责可读上下文，errors.Is 负责稳定的程序判断，两种需求没有混在一段字符串里。

求值代码直接使用第一个参数，所以空参数必须先被 Check 拒绝。若 API 不能保证先检查，Eval 也应改为返回 (float64, error)，把前置条件放进类型契约。

用 error 返回未知类型比 panic 更适合库边界。真实 SQL 字符串规则由数据库方言决定，参数化查询还负责防注入和正确编码，因此这个函数不能代替驱动。

可用 bytes.Buffer 测试基础路径，再定义一个包装类型记录 Flush 是否被调用。失败路径可准备一个总是返回哨兵错误的 writer，并用 errors.Is 验证包装后仍能识别底层错误。不要通过匹配完整错误字符串判断错误身份。