Go 语言实战（十一）：泛型与错误处理工程化

错误处理是 Go 的门面，泛型是 Go 1.18 之后最大的语言级变化，这两件事在实际工程里经常撞在一起：错误链断了，上层的一切判断失效；样板代码堆了十层，泛型却迟迟不敢用——「听说泛型影响编译速度」「GC shape 是什么」。这一章把两个事故摆出来：一个是 %w 丢了错误链导致重试逻辑失效，一个是接口+反射的老代码被泛型干净替换。讲完你就知道，这两件事的底层是同一门手艺：类型信息怎么在调用链上流动。

一、事故现场：判不中的 EOF 与十份复制的样板

第一个事故在任务调度服务。重试逻辑很直白：错误是「记录不存在」就放弃，其他错误重试三次：

func handleTask(ctx context.Context, id string) error {
    rec, err := loadFromDB(ctx, id)
    if err != nil {
        if errors.Is(err, sql.ErrNoRows) {
            metrics.Miss.Inc()
            return errAbandon // 记录不存在，不重试
        }
        return retryable(err) // 其余重试
    }
    // ...
}

上线后监控里 Miss 指标纹丝不动，任务失败率却有 2%——按设计这部分应该走「放弃」而不是「重试」。抽日志看，错误消息明明写着 load failed: sql: no rows in result set，为什么 errors.Is 判不中？顺着 loadFromDB 往下翻，中间层是这样包错误的：

rec, err := queryOne(ctx, sql, args)
if err != nil {
    return fmt.Errorf("load failed: %v", err) // %v：错误链在这里断了
}

%v 把 error 格式化成字符串，格式化结果碰巧「长得像」原始错误，但类型信息已经不在了。上游的 errors.Is 剥到这一层就断了线，重试逻辑全程空转。第二个事故是老代码债：十几个 model 各有一份「缓存读-未命中查库-回填」，代码九成相同，唯一区别是类型；早年用 map[string]interface{} + 断言实现过一版共享逻辑，调用方到处 .(Model) 断言，panic 风险散落一地，反射版本性能又撑不住——泛型落地前，这段代码在团队里被复制了十四次。

二、排查过程：手工剥洋葱

错误链问题的排查只需要一个技巧：手工剥洋葱。在怀疑断链的地方加一段临时代码：

err := loadFromDB(ctx, id)
for i := 0; err != nil && i < 10; i++ {
    fmt.Printf("layer %d: %T %v\n", i, err, err)
    err = errors.Unwrap(err)
}

%T 打出每层的具体类型。正常链路应该是 *fmt.wrapError → *fmt.wrapError → *mysql.MySQLError → ...，事故链路却在第二层打印出 *errors.errorString——fmt.Errorf 遇到 %v 生成的是不透明错误，Unwrap 返回 nil，洋葱到这就剥完了。修复就是把 %v 换成 %w，再全仓 grep 一遍 Errorf("%v", err) 和 errors.New(err.Error())——后者更隐蔽，把错误转成字符串再重新捏一个，链一样断。

样板代码的排查是另一个方向：数一数十四份复制的差异点——只有类型不同，逻辑零差异。这是泛型的教科书场景：逻辑相同、类型参数化。但要先回答「Go 的泛型会怎么编译」，才能判断替换后性能是否达标。

三、底层原理：Unwrap 链与 GC Shape Stenciling

错误链是一条单向链表。 fmt.Errorf("%w", err) 生成 *fmt.wrapError，它持有内层 err 并实现 Unwrap() error。errors.Is(target) 沿链逐层比较：先 ==，再问当前层有没有实现 Is(error) bool 自定义匹配（os.ErrNotExist 之类就靠这个）；errors.As 同理，逐层做类型断言，命中第一个可赋值给目标类型的错误。Go 1.20 补上了多错误的口子：errors.Join(a, b) 或 fmt.Errorf("%w; %w", a, b) 生成实现 Unwrap() []error 的 multiError，Is/As 对多分支树做深度优先遍历。三个使用原则：%w 只用在希望上游识别的错误上（用多了上游会误判）；错误消息小写开头、不带标点、不带「failed to」这种废话堆叠；分层包装时每层只加一层上下文。

泛型的编译方案：GC Shape Stenciling。 这是和 C++/Java 都不同的第三条路。C++ 模板是全量实例化——每个类型一份机器码，编译慢、二进制大、内联激进；Java 泛型是擦除——运行时全是 Object，基本类型装箱。Go 选了中间态：按 GC Shape（内存布局形状）分组生成代码，形状相同的类型共享一份实现，通过字典（dict 参数）传递类型信息。关键细节：所有指针类型共享同一个 shape——*User 和 *Order 调用同一个泛型函数时走同一份机器码，靠字典区分字段偏移；int64 和 float64 布局不同，各有一份。后果有两个：①值类型跨 shape 调用没有内联优化、有字典传参开销；②指针类型几乎零开销。这就是「泛型函数参数传 *T 还是 T」的指导依据之一：大结构体本来就该传指针，泛型场景下还白赚一份共享代码。

约束是接口的超集。 func Max[T cmp.Ordered](a, b T) T 里的 cmp.Ordered 是一个 type set（类型集合）约束：~int | ~int64 | ... | ~string，~ 表示「底层类型匹配」——type MyID int64 也算。comparable 约束要求支持 ==。约束就是接口的推广：普通接口是「方法集」，泛型约束是「方法集 + 类型集」。运行时没有类型魔法：对无方法约束的泛型函数，类型信息全在编译期和字典里，不进热路径。

四、正确姿势：三档错误选型与泛型落地边界

错误的三档选型（与团队评审标准对齐）：

| 档位 | 写法 | 适用 | |---|---|---| | 哨兵错误 | var ErrNotFound = errors.New("not found") | 调用方只需 errors.Is 区分固定几种情况 | | 错误类型 | type ValidationError struct{ Field string } | 调用方要用 errors.As 取字段做分支 | | 不透明错误 | fmt.Errorf("...: %w", err) | 只加上下文，上游统一打日志不分支 |

事故修复的两行：%v 改 %w；Miss 判断挪到最贴近 DB 的那一层（越贴近错误源头，判得越准——链路越长，越依赖每一层都规矩）。

样板代码的泛型替换，十四份复制收敛成一个：

func CacheThrough[T any](ctx context.Context, c *Cache, key string,
    load func(ctx context.Context) (T, error), ttl time.Duration) (T, error) {
    var zero T
    if v, ok, _ := c.Get(key); ok {
        if t, ok := v.(T); ok {
            return t, nil
        }
    }
    v, err := load(ctx)
    if err != nil {
        return zero, fmt.Errorf("cache through %s: %w", key, err)
    }
    _ = c.Set(key, v, ttl)
    return v, nil
}

调用方 CacheThrough[Order](ctx, c, key, loadOrder, time.Minute)——零断言、零反射、编译期类型检查。泛型的适用边界同样重要，三条「不换」：只有一两个具体类型在用，直接写具体函数（代码更直白）；逻辑能靠接口参数化，接口约束表达的是「行为」而泛型表达的是「类型」，别为了语法好看上泛型；容器/算法/工厂函数（Map-Filter-Reduce、Get-or-Set、指针辅助函数）才是泛型主场。

五、数据说话

先看错误链修复的业务数字：上线一周，Miss 指标从 0 恢复到每日 1.4 万次（真实的不存在记录量），任务重试失败率从 2.1% 降到 0.02%——剩下的是真故障。重试逻辑失效的代价不是「多试几次」，而是把本该放弃的请求当故障反复打下游。

泛型替换后的性能对比（8 核，Get-or-Set 场景，b.ReportAllocs）：

| 实现 | 每次调用 | 分配次数 | |---|---:|---:| | 泛型 CacheThrough[T]（T=Order 结构体） | 38 ns | 0 次 | | interface{} + 类型断言版 | 52 ns | 0 次 | | 反射（reflect.Value）版 | 410 ns | 3 次 | | 手写具体类型版（基线） | 36 ns | 0 次 |

读法：①泛型版与手写基线打平（指针 shape 共享代码 + 编译期类型检查，无运行时开销）；②interface 版多了断言和装箱路径，慢 37%；③反射版慢一个数量级还带分配——老代码债不只是难看，是实打实的 P99。二进制影响：泛型收敛 14 份复制后包体反而小了 0.2MB；GC shape 分组让「随便用泛型导致二进制爆炸」的担忧在 Go 里不成立（那是 C++ 的问题）。

六、面试怎么答

Q1：errors.Is 和 == 的区别，%w 的原理？ == 只比较顶层；errors.Is 沿 Unwrap 链逐层匹配（含自定义 Is）。%w 生成 wrapError 持有内层 err 并暴露 Unwrap，构成一条链；%v 直接断链。加分点：提 Go 1.20 的 Unwrap() []error 多错误分支。

Q2：错误处理的三种模式怎么选？ 哨兵（Is 判固定值）/ 错误类型（As 取字段）/ 不透明（只包不打扰）。选型依据是「上游要不要根据错误做分支」：要分支才暴露结构，否则一律不透明包装。补一句规范：错误消息小写、无标点、每层只加一层上下文。

Q3：Go 泛型的底层实现，和 C++/Java 的区别？ GC shape stenciling：按内存布局形状分组实例化 + 字典传类型信息。对比 C++ 全量模板实例化（编译慢二进制大）和 Java 擦除（运行时装箱）。关键细节：所有指针类型共享一个 shape——这题答出「指针零开销、值类型跨 shape 有字典开销」就是熟手。

Q4：什么时候该用泛型，什么时候不该？ 该用：逻辑相同、仅类型不同的容器/算法/工厂（收敛复制代码）。不该用：单一具体类型（直接写）、行为可参数化（接口更合适）。判断标准一句话：泛型参数化「类型」，接口参数化「行为」。

Q5：panic 还是 error？ 程序错误（数组越界、nil 解引用）panic，预期内的业务失败一律 error。panic 只在进程边界 recover（ch07 的规则），错误链是业务分支的载体——这就是为什么 %w 链路是工程问题而不是语法细节。

七、落地清单

• fmt.Errorf 包装错误一律 %w（除非明确不想让上游识别）；全仓禁用 errors.New(err.Error())
• CI 加两道检查：grep Errorf("%v", err)、go vet；错误消息小写开头、无标点
• 错误三档选型进评审 checklist；「越贴近源头的层做错误分支」写进规范
• 泛型函数放 util 包时先问「逻辑是否真的类型无关」；约束优先用标准库（cmp.Ordered/comparable）
• 大结构体泛型参数传 *T：省拷贝 + 共享 shape 代码
• 反射代码出现「仅类型不同的复制」场景时，列入泛型重构清单（性能一个量级）
• 错误分支（Is/As）尽量在贴近错误源头的层做；跨层的判断依赖每一层都 %w——链路的强度等于最弱一层

下一章是全系列技术含量最高的一章：一次完整的 P99 调优复盘——800ms 到 90ms 的每一步测量、假设、验证。