go接口组合的核心是小接口、按需组合：只含1–2个方法，-er命名，定义在使用处；禁止嵌入struct，避免方法签名冲突，nil panic发生在方法调用时而非声明时。
Go 接口组合不是“把一堆方法塞进一个大接口”，而是让调用方只看到它真正需要的行为。小接口、明确职责、按需组合，才是可维护和可测试的起点。
怎么写一个能被组合的小接口
小接口必须满足三个条件：只包含一个或两个方法、命名用 -er 后缀、定义在使用它的函数附近。比如你正在写一个日志上报模块，它只调用了 Write 和 Close，那就别提前定义 Logger 或 Uploader——直接写：
type Writer interface {
Write(p []byte) (n int, err error)
}
type Closer interface {
Close() error
}
这两个接口在标准库中已存在，且被广泛实现，复用它们比自定义更安全。不要为了“统一管理”而新建一个 LogWriter 接口，除非你真有第三个方法要加。
- 避免在接口里放
Context参数——那是实现细节，不是行为契约 - 如果某个方法只在 10% 场景下被调用，就别把它塞进共用接口里
- 接口名别带业务词（如
UserStorer），优先用通用动词（Storer、Fetcher）
组合接口时为什么不能直接嵌入 struct
接口组合只能嵌入其他接口，不能嵌入 struct。写 type MyInterface interface { *SomeStruct } 是语法错误，Go 会报 invalid use of unexported field or method。常见错误是混淆了“接口组合”和“结构体嵌入”两种机制：
- 接口组合：合并方法签名，用于类型约束，如
type ReadCloser interface { Reader; Closer } - 结构体嵌入：复用字段和方法，用于实现逻辑复用，如
type FileService struct { *os.File } - 两者目的不同，混用会导致编译失败或语义错乱——比如你本想约束行为，结果误传了一个具体 struct 实例
如果你发现总想往接口里塞 struct，说明你其实在写实现，而不是定义契约。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
组合后方法冲突怎么排查
当两个被组合的接口有同名方法但签名不同时，Go 编译器会直接拒绝，报错类似 duplicate method XXX。这不是运行时问题，是编译期硬性限制。典型场景是：
-
type A interface { Do(x int) error }和type B interface { Do(y string) error }组合成C interface { A; B }→ 编译失败 - 标准库中
io.Reader和自定义Reader（返回[]byte而非(n int, err error)）强行组合 → 报错
解决办法只有一个：重命名其中一个接口，或拆分职责。比如把读配置的接口叫 ConfigLoader，读网络流的叫 StreamReader，不强行共用 Reader 这个名字。
nil 接口 panic 的真实触发点在哪
panic 不发生在接口声明时，而是在第一次调用其方法时。比如：
var r io.Reader // 此时 r == nil r.Read(buf) // panic: nil pointer dereference
最容易被忽略的是构造函数漏初始化、mock 注入失败、或错误分支返回 nil 接口值：
- 字段未赋值：
type Svc struct { db DB }; func NewSvc() *Svc { return &Svc{} }→svc.db是 nil 接口 - 函数返回接口时没兜底：
func GetReader(...) (io.Reader, error) { if err != nil { return nil, err } ... }→ 调用方拿到nil后直接调Read就崩 - 测试时用
gomock但忘记EXPECT()对应方法，mock 对象实际是 nil 实现
真正该检查的不是“有没有 nil”，而是“谁负责保证非 nil”——这个责任必须落在构造函数或工厂函数上，不能靠调用方防御性判空。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
