一个函数返回 error，调用方判断 err != nil 进了错误分支，结果 err.Error() 空指针 panic——这是一个"装着 nil 指针的接口值"。另一个现场：ORM 用反射拼装结构体，Set 报 reflect.Value.Set using unaddressable value，代码看起来没问题。两者同源：接口是两段式结构，反射按地址规则操作。按 Go 1.22 起的语义拆。
1. 两类接口的内部表示
| 内部类型 | 对应接口 | 字段 | 说明 |
|---|---|---|---|
eface |
any（空接口） |
_type + data |
没有方法表，只有类型与数据指针 |
iface |
非空接口 | tab（itab：类型 + 方法表）+ data |
方法调用走 tab 里的函数指针 |
type eface struct {
_type *_type
data unsafe.Pointer
}
type iface struct {
tab *itab // itab 缓存了类型与方法实现
data unsafe.Pointer
}
itab 是"接口方法与实际函数地址"的映射，第一次赋值时生成并缓存，之后同类型同接口的转换可复用。接口方法调用是一次间接跳转，比直接调用多一层间接，但比反射快得多。
2. "接口值 == nil" 的经典陷阱
func find() error {
var p *MyError = nil
return p // 返回了一个"装着 nil 指针的非 nil 接口"
}
if err := find(); err != nil {
fmt.Println(err.Error()) // panic: nil pointer dereference
}
| 判断方式 | 结果 | 说明 |
|---|---|---|
| 接口值为 nil | tab == nil && data == nil |
只有两段都空才是 nil |
返回 (*T)(nil) 作为接口 |
不是 nil | tab 非空，data 是 nil |
errors.Is(err, (*MyError)(nil)) |
可用 | 显式比较类型 |
| 返回前判空 | 正确做法 | if p == nil { return nil } |
修复原则只有一条：返回接口前，先判断具体值是否为 nil。
func find() error {
var p *MyError
if p == nil {
return nil // 返回真正的 nil 接口
}
return p
}
这个陷阱在 defer 里也有变体：defer f(err) 捕获的是当时的接口值，而 defer func(){ ... }() 闭包读取的是变量最终值。
3. 方法集规则
| 接收者 | 方法集属于 T |
方法集属于 *T |
能满足接口 I 的是 |
|---|---|---|---|
值接收者 func (t T) M() |
是 | 是 | T 与 *T 都可 |
指针接收者 func (t *T) M() |
否 | 是 | 只有 *T |
type Counter struct{ n int }
func (c *Counter) Inc() { c.n++ } // 指针接收者
var i interface{ Inc() } = Counter{} // 编译错误：Counter 未实现 Inc
var i interface{ Inc() } = &Counter{} // 正确
指针接收者不能被值类型满足，原因是语义：Inc 要修改接收者，而接口里存的 data 若是值副本，修改就丢了。经验规则：只要有一个方法用指针接收者，就统一用指针接收者，否则同一个类型会出现"值能调一部分方法、指针能调全部"的割裂。
4. 接口断言
v, ok := x.(io.Reader) // 安全形式：失败返回零值与 false
v := x.(io.Reader) // 直接形式：失败 panic
switch t := x.(type) { // 类型开关，t 是对应具体类型
case string: _ = t
case []byte: _ = t
default: _ = t
}
| 形式 | 失败行为 | 适用 |
|---|---|---|
v, ok := x.(T) |
返回 nil/零值 + false |
不确定类型时的首选 |
v := x.(T) |
panic | 逻辑上保证成立时（如内部调用） |
switch x.(type) |
走 default |
多分支类型分派 |
errors.As(err, &target) |
返回 bool，可穿透包装 | 错误类型提取 |
errors.As 与直接断言的区别：它会沿 Unwrap 链查找，因此错误处理里应该用 errors.As 而不是 err.(*T)。
5. 隐式实现与"接口该由谁定义"
// 调用方定义小接口（消费者驱动）
package consumer
type Store interface {
Get(ctx context.Context, id string) (Item, error)
}
| 做法 | 结果 |
|---|---|
| 提供方定义大接口（10 个方法） | 所有调用方被强绑，mock 需要实现全部方法 |
| 调用方定义小接口（1–3 个方法） | mock 简单，实现自由组合 |
| 提前抽接口"以备扩展" | 接口数量膨胀，实际只有一个实现 |
| 抽象在具体类型出现之后 | 接口形状来自真实需求 |
Go 的隐式实现让"调用方定义接口"极其自然：不需要提供方配合，*MySQLStore 只要方法签名对上就自动满足。这条能力最常被浪费——很多代码把接口定义在提供方包里，并且一次定义十个方法，于是每个测试都要写十个空实现。
判据：接口应该由使用它的人定义，并且尽量小。io.Reader 只有一个方法，所以能复用二十年。
6. any 的代价
func sum(vals []any) int { // 每个元素都要装箱
s := 0
for _, v := range vals {
s += v.(int) // 类型断言，失败即 panic
}
return s
}
| 代价 | 机制 | 影响 |
|---|---|---|
| 装箱（boxing） | 值类型放进 eface 需要堆上分配 |
分配次数上涨、GC 压力 |
| 逃逸 | 取地址放入 data 时对象逃逸到堆 |
栈分配机会丢失 |
| 类型安全 | 断言失败在运行期才暴露 | 编译期检查失效 |
| 可读性 | 断言散落各处 | 调用链难追踪 |
[]any 的每个元素都可能是一次堆分配。Go 1.18 起有泛型，能用类型参数的地方不要用 any：func Sum[T ~int|~int64](vals []T) T 零装箱、零断言。
7. 反射三定律
| 定律 | 含义 | 对应 API |
|---|---|---|
| 1 | 接口值 → reflect.Type / reflect.Value |
reflect.TypeOf(i)、reflect.ValueOf(i) |
| 2 | Value → 接口值 |
v.Interface() |
| 3 | 要修改值，Value 必须可寻址（通常通过指针） |
reflect.ValueOf(&x).Elem().Set(...) |
type T struct{ Name string; Age int }
t := reflect.TypeOf(T{})
v := reflect.ValueOf(&T{}).Elem() // Elem() 解引用，得到可寻址的 Value
for i := 0; i < t.NumField(); i++ {
f := t.Field(i)
fmt.Println(f.Name, f.Type, f.Tag.Get("json")) // 读标签
}
v.FieldByName("Name").SetString("yg") // 只有在可寻址时才能 Set
reflect.Type 是只读的类型描述（可缓存、可比较），reflect.Value 是值的容器（带可寻址性标记）。反射慢的根源在 Value 的装箱与边界检查，不在 Type。
8. 可用场景与代价
| 场景 | 是否值得 | 理由 |
|---|---|---|
| 序列化/反序列化 | 是（库内部） | 字段名与类型必须运行期读取 |
| ORM 字段映射 | 是 | 表结构在运行期才确定 |
测试断言（reflect.DeepEqual） |
是 | 通用比较无法静态表达 |
| 业务代码里做字段拷贝 | 否 | 用生成代码或显式赋值 |
| 动态调用"看起来灵活" | 否 | 编译期检查全丢，重构即崩 |
// 性能敏感处：用代码生成替代运行期反射
//go:generate go run github.com/.../copier-gen
代价可以量化：反射路径通常比直接字段访问慢一到两个数量级（按实测环境与版本核对），并且无法被内联、无法被逃逸分析优化。所以标准做法是"反射只用于初始化阶段建立映射，热路径走缓存好的 StructField 索引或生成代码"。
9. 修改值必须可寻址
x := 1
reflect.ValueOf(x).SetInt(2) // panic: using unaddressable value
reflect.ValueOf(&x).Elem().SetInt(2) // 正确：Elem() 后可寻址
| 操作 | 前置条件 | 检查方法 |
|---|---|---|
Set* |
CanSet() 为 true |
v.CanSet() |
Addr() |
CanAddr() 为 true |
v.CanAddr() |
| 修改未导出字段 | 不可 Set，即使可寻址 | PkgPath 非空的字段无法写 |
| 读未导出字段 | 可读，Interface() 受限 |
按版本核对行为 |
CanSet 为 false 的三种情况：值来自 reflect.ValueOf(非指针)、字段未导出、值来自 map 元素或函数返回值。先判 CanSet 再 Set，是反射代码的基本纪律，否则线上一次字段改名就变成 panic。
10. 结构体标签解析
type User struct {
ID int `json:"id" db:"user_id" validate:"required"`
Name string `json:"name,omitempty"`
}
tag := reflect.TypeOf(User{}).Field(0).Tag
jsonName := tag.Get("json") // "id"
raw := tag.Get("validate") // "required"
lookup, ok := tag.Lookup("db") // "user_id", true
| 写法 | 返回 | 注意 |
|---|---|---|
Tag.Get("json") |
值或空串 | 无法区分"没有该 key"与"值为空" |
Tag.Lookup("json") |
(值, 是否存在) |
需要区分时用这个 |
| 标签语法 | key:"value" 空格分隔 |
值里的引号需转义，非法标签 Get 返回空 |
| 同名 key | 取第一个 | 不要重复写 |
标签是运行期字符串，拼错不会报错，只会静默失效。这是"加了 json:"userId" 但输出还是 UserId"的唯一原因——通常是标签里有空格或用了中文引号。
11. 排错表：常见坑
| 坑 | 表现 | 修法 |
|---|---|---|
| 把接口当泛型用 | 到处 any + 断言 |
用类型参数 |
反射对不可寻址值 Set |
using unaddressable value |
传指针 + Elem()，先判 CanSet |
any 做容器 |
类型断言到处飞、panic 难定位 | 定义具体类型或泛型容器 |
| 接口定义过宽 | mock 需要实现一堆方法 | 调用方定义 1–3 个方法的小接口 |
返回 (*T)(nil) 当接口 |
err != nil 但值为空 |
返回前判空 |
| 标签拼错 | 序列化字段名不对 | Lookup + 单测断言 |
12. 边界表
| 场景 | 该用的手段 | 理由 |
|---|---|---|
| 需要多态 | 小接口 | 隐式实现、mock 简单 |
| 需要通用容器 | 泛型 | 零装箱、编译期检查 |
| 运行期读结构 | 反射（仅初始化阶段） | 字段名只有运行期可得 |
| 热路径字段访问 | 生成代码 / 缓存索引 | 反射无法内联 |
| 错误类型提取 | errors.As |
穿透包装 |
| 判断接口是否 nil | 与 nil 直接比较，但先确认返回的是真 nil |
两段式结构 |
一句话：接口解决"调用方不知道具体类型"，反射解决"编译期不知道结构"。两者都是必要工具，但一旦出现在业务热路径上，通常说明设计少了一层抽象。
13. 自测
eface与iface的结构差异是什么？方法调用走哪个字段？- 返回
(*MyError)(nil)作为error，err != nil为什么为真？ - 指针接收者方法为什么不能被值类型满足接口？
Tag.Get与Tag.Lookup的区别，为什么拼错的标签不报错？- 反射
Set报unaddressable的两个常见原因是什么？ - 为什么说"接口该由调用方定义"？这对 mock 有什么实际影响？