Go · interface 与动态派发

场景 1 · 存储层抽象: Store 接口 + redis/mysql 双实现 + 内存 fake

订单域只关心"取/存字节", 不该被具体存储绑架; 测试也不该为了一条路径起真 Redis:

type Store interface {                                   // 定义在使用侧: 域内只要这两个方法
    Get(ctx context.Context, key string) ([]byte, error) // 只依赖行为, 不依赖介质
    Set(ctx context.Context, key string, val []byte, ttl time.Duration) error
}

type redisStore struct{ r *redis.Client }                 // 指针接收者: 连接池绝不能被拷贝
func (s *redisStore) Get(ctx context.Context, key string) ([]byte, error) {
    return s.r.Get(ctx, key).Bytes()
}
func (s *redisStore) Set(ctx context.Context, k string, v []byte, ttl time.Duration) error {
    return s.r.Set(ctx, k, v, ttl).Err()
}

type memStore struct{ m map[string][]byte }               // 测试 fake: 内存实现同样满足 Store
func (s *memStore) Get(_ context.Context, k string) ([]byte, error) {
    v, ok := s.m[k]                                          // 单测注入它, 不碰真 Redis, ms 级跑完
    if !ok { return nil, ErrNotFound }
    return v, nil
}

场景 2 · io.Reader/Writer 流式管道: 10GB 备份, 512MB 内存跑通

全量读进内存必炸; 整条链路用 Reader/Writer 组合, 中间任何一环都能替换:

func archive(ctx context.Context, src io.Reader, dst io.Writer) error {
    gw, _ := gzip.NewWriterLevel(dst, gzip.BestSpeed)   // 压缩先行: 级别换 CPU, 管道内存恒定
    defer gw.Close()                                       // 不 Close 尾块丢失 → 文件损坏
    ew := &encWriter{w: gw}                                  // 自定义 Writer 实现 AES-GCM 加密
    buf := make([]byte, 256<<10)                          // 256KB 滑动窗口: 与文件大小无关
    for {
        if err := ctx.Err(); err != nil { return err }    // 支持取消: 备份中途可停
        n, err := src.Read(buf)
        if n > 0 {
            if _, werr := ew.Write(buf[:n]); werr != nil { return werr }
        }
        if err == io.EOF { return nil }
        if err != nil { return fmt.Errorf("archive read: %w", err) }
    }
}

收益: 峰值内存 = 缓冲区大小, 10GB 流照跑; 中间加解密/上报环都是十几行的 Writer 装饰。

场景 3 · type switch 处理多态 webhook payload

支付回调同一字段可能是对象/数组/字符串, 断言链写到底不如一次分派:

func handleEvent(evt map[string]any) error {
    raw, _ := json.Marshal(evt["payload"])
    var v any
    if err := json.Unmarshal(raw, &v); err != nil { return err }
    switch p := v.(type) {                              // 按动态类型分派, 各自结构不同
    case map[string]any:                                 // charge.succeeded: 对象
        id, _ := p["id"].(string)
        amt, _ := p["amount"].(float64)
        return handleCharge(id, amt)
    case []any:                                           // batch.refunded: 数组逐条
        for _, it := range p {
            if m, ok := it.(map[string]any); ok { handleRefund(m) }
        }
        return nil
    case string:                                           // 旧版纯文本事件: 兼容分支
        return handleLegacy(p)
    case nil:                                              // 空事件: 显式忽略而非 panic
        return nil
    default:
        return fmt.Errorf("unknown payload type %T", v) // 新类型进 default, 可见可查
    }
}

场景 4 · 单测 mock 取舍: 手写函数字段 stub vs gomock

接口 ≤3 个方法时手写 fake 十几行最直观; 方法一多才轮到 gomock/mockery:

// 手写 stub: 函数字段让每个用例现编行为, 断言"调用过什么"也直接
type stubStore struct{
    get func(ctx context.Context, k string) ([]byte, error) // 每用例注入不同实现
    setCalls int                                          // 顺手计数, 验证写入次数
}
func (s *stubStore) Get(ctx context.Context, k string) ([]byte, error) { return s.get(ctx, k) }
func (s *stubStore) Set(_ context.Context, _ string, _ []byte, _ time.Duration) error {
    s.setCalls++
    return nil
}

func TestOrderCacheMiss(t *testing.T) {
    st := &stubStore{get: func(_ context.Context, _ string) ([]byte, error) {
        return nil, redis.Nil                               // 模拟未命中: 业务走回源分支
    }}
    svc := NewOrderService(st)
    ... // 断言回源后 st.setCalls == 1: 未命中后写回缓存
}

场景 5 · 逗号-ok 断言防 panic 的连接升级分支

网关里拿到的连接可能是 *tls.Conn 也可能是裸 TCP, 裸断言一个脏连接就炸整个 worker:

if tlsConn, ok := conn.(*tls.Conn); ok {              // 逗号-ok: 失败只是 false
    st := tlsConn.ConnectionState()                     // TLS 连接: 拿 ALPN 协商结果
    if st.NegotiatedProtocol == "h2" {
        return serveHTTP2(tlsConn)
    }
    return serveHTTP1(tlsConn)
} else if tcp, ok := conn.(*net.TCPConn); ok {        // 明文: 补 TCP 保活
    tcp.SetKeepAlive(true)
    tcp.SetKeepAlivePeriod(90 * time.Second)
    return serveHTTP1(tcp)
}
return fmt.Errorf("unsupported conn type %T", conn) // 未知类型显式报错, 不静默

场景 6 · 装饰器: 用接口包 http.RoundTripper 做重试与慢日志

http.Client 的扩展点就是 Transport 接口, 包一层就是中间件, 不用碰业务代码:

type logTransport struct{ next http.RoundTripper }
func (t *logTransport) RoundTrip(req *http.Request) (*http.Response, error) {
    start := time.Now()
    resp, err := t.next.RoundTrip(req)                  // 装饰: 包住默认 Transport
    if d := time.Since(start); d > 800*time.Millisecond {
        log.Warnf("slow upstream %s %s cost=%s", req.Method, req.URL.Path, d)
    }
    return resp, err
}

type retryTransport struct{ next http.RoundTripper }
func (t *retryTransport) RoundTrip(req *http.Request) (*http.Response, error) {
    var lastErr error
    for i := 0; i < 3; i++ {                              // 只有幂等 GET 才敢自动重试
        if req.Method != http.MethodGet { break }
        resp, err := t.next.RoundTrip(req)
        if err == nil { return resp, nil }
        lastErr = err                                    // 网关超时/连接重置才值得重试
    }
    return nil, lastErr
}

client := &http.Client{Timeout: 5 * time.Second,     // 洋葱式装配: 日志包重试包默认
    Transport: &logTransport{next: &retryTransport{next: http.DefaultTransport}}}

场景 7 · Feature 接口做功能开关, 配置驱动热切换灰度

推荐 V2 要 5% → 50% → 100% 放量, 回滚只换装配不改代码:

type Feature interface{ Enabled(ctx context.Context, uid int64) bool }

type staticFeat struct{ on bool }                         // 阶段1: 配置中心一刀切
func (f *staticFeat) Enabled(context.Context, int64) bool { return f.on }

type rolloutFeat struct{ rdb *redis.Client }              // 阶段2: 按桶百分比放量
func (f *rolloutFeat) Enabled(ctx context.Context, uid int64) bool {
    v, err := f.rdb.Get(ctx, fmt.Sprintf("feat:rec:v2:%d", uid%100)).Int()
    return err == nil && v == 1                            // 桶号命中开白名单
}

type RecService struct{ v2 Feature }                      // 依赖接口: 运行时换实现
func (s *RecService) Rec(ctx context.Context, uid int64) []Item {
    if s.v2.Enabled(ctx, uid) { return s.recV2(ctx, uid) }
    return s.recV1(ctx, uid)                             // 事故回滚: 装回 staticFeat{false}
}

场景 8 · 隐式接口解耦第三方 SDK: consumer 侧定义窄接口

业务包直接 import 短信 SDK, SDK 一升级全量重编译还连带测试; 倒置依赖方向:

// package sms (业务包) — 不 import 任何第三方 SDK, 只声明自己要的形状
type Sender interface{ Send(ctx context.Context, phone, text string) error }

type Service struct{ s Sender }
func New(s Sender) *Service { return &Service{s: s} }     // 阿里云/腾讯云谁满足谁进来

// package smsali (适配层) — 全项目唯一 import 那个 SDK 的地方
type aliAdapter struct{ cli *aliyun.Client }
func (a *aliAdapter) Send(ctx context.Context, phone, text string) error {
    req := aliyun.NewSendRequest(phone, text, "中秋活动", "TPL_001")
    _, err := a.cli.Do(ctx, req)                          // SDK 细节被关在适配层里
    return err
}
// 换供应商 = 换一行装配; 单测给 Sender 塞 fake, SDK 永远不进测试进程

场景 9 · sort.Interface 一句话引出泛型: 排序的两次进化

老接口三方法样板代码一堆还要付派发钱, 1.21+ 泛型一行零派发:

// 旧写法: 实现 sort.Interface 三方法 (Len/Less/Swap) 才能排
type ByDeadline []*Task
func (a ByDeadline) Len() int           { return len(a) }
func (a ByDeadline) Less(i, j int) bool { return a[i].deadline < a[j].deadline }
func (a ByDeadline) Swap(i, j int)      { a[i], a[j] = a[j], a[i] }
sort.Sort(ByDeadline(tasks))                             // 接口派发 + 不稳定排序

// 新写法 (Go 1.21+): 泛型实例化, 零接口派发开销
slices.SortFunc(tasks, func(a, b *Task) int {
    return a.deadline.Compare(b.deadline)             // cmp 三态: 负/零/正
})
// 容器与算法选泛型, 运行时多态才留给接口 —— 分工明确

场景 10 · pprof 排查接口装箱逃逸: allocs 里的 convT64

埋点函数把 int 塞进 any 每秒四千万次, allocs 火焰图一片 convT64 占 9%:

// 现象: go tool pprof -sample_index=alloc_objects heap
//   runtime.convT64  39,812,044 (9.2%)  ← 接口装箱现场
func track(sh *metrics.Handler, route string, costMs int) {
    sh.Observe("route_cost", map[string]any{    // any 装箱: 每次调用 2 个堆对象
        "route": route, "ms": costMs,               // string/int 全部逃逸
    })
}

// 修复: 热路径改具体类型签名, 不走 any 装箱
sh.ObserveInt("route_cost_ms", route, costMs)     // int 直进环形数组, 零分配

// 验证: go test -bench=. -benchmem
//   BenchmarkTrack-8   allocs/op  2 → 0, ns/op  142 → 38

收益: 埋点链路 CPU 降 8%, GC 压力同步下降 —— 接口的灵活是拿分配买的。