go接口解耦核心在于精准定义行为契约、依赖注入与小接口组合，而非堆砌接口数量；错误做法包括暴露实现细节、使用具体类型、全局变量注入及大接口，正确方式是返回最小契约类型、按需组合小接口、避免hot path接口调用。
Go里接口解耦不是靠堆接口数量，而是靠精准定义行为契约 + 依赖注入 + 小接口组合。做不好反而增加调用跳转和抽象泄漏。
接口定义必须只暴露行为，不暴露实现细节
常见错误是把数据库字段、结构体嵌套或HTTP状态码塞进接口方法签名里，导致实现被绑定死。比如 GetUserByID(id int) (*User, error) 看似合理，但 *User 如果含 CreatedAt time.Time 字段，就强制所有实现（MySQL/Redis/Mock）都得构造完整结构体，哪怕只是查ID和Name。
- 正确做法：返回最小契约类型，如
type UserView interface { GetID() int; GetName() string } - 避免在接口中使用具体类型：不用
*sql.Rows、http.ResponseWriter、json.RawMessage - 方法参数尽量用基础类型或小接口：
id string比id *uuid.UUID更易 mock 和替换
依赖注入时别让 handler 或 router 直接 new 实现
在 Gin 或 HTTP server 中写 userService := &UserServiceImpl{} 是典型耦合点。一旦需要换 Redis 实现或加缓存层，就得改路由逻辑。
- 把具体实现交给容器初始化：用
container.NewContainer()一次性构建所有依赖树 - handler 函数接收已注入的接口实例，而非自己创建：
func GetUserHandler(ctx *gin.Context, svc UserService) - 避免全局变量注入：不要用
var userService UserService = &UserServiceImpl{}，它破坏可测试性且无法按环境切换
组合小接口比定义大接口更利于演进
一个叫 UserRepository 的接口如果包含 Create、Update、Delete、Search、Count 五个方法，那 mock 测试时就得实现全部——哪怕当前用例只读不写。
- 拆成
UserReader和UserWriter两个接口，按需注入 - 复用标准库接口：优先用
io.Reader、io.Writer、fmt.Stringer，而不是另造ReadFromDB()这类方法 - 组合示例：
type UserStore interface { UserReader; UserWriter; UserSearcher }，但只在真正需要三者的地方使用该组合
性能陷阱：接口不是零成本抽象
每次通过接口调用方法都会引入一次动态分派（interface dispatch），在高频路径（如日志写入、序列化循环）中可能成为瓶颈。
- 对性能敏感路径，考虑用函数类型替代接口：比如
type Encoder func(v interface{}) ([]byte, error)比type Encoder interface { Encode(v interface{}) ([]byte, error) }少一层间接 - 避免在 hot path 上做不必要的接口转换：
var w io.Writer = os.Stdout没问题，但for i := range data { w.Write(data[i]) }中反复调用w.Write会放大 dispatch 开销 - 编译器能内联的具体类型调用（如直接调
json.Marshal）永远比接口调用快；接口适合隔离变化点，不是通用加速器
最常被忽略的是：接口边界一旦划错，后续所有 mock、替换、重试逻辑都会跟着偏移。与其追求数量或“看起来很解耦”，不如先问一句——这个接口，是否真的会在两个以上完全不同的实现之间切换？如果不是，就先用具体类型。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
