17370845950

Go解耦本质是隐式实现接口：结构体只要实现接口方法签名即自动满足，调用方只依赖接口契约；应传接口而非具体类型，通过依赖注入将创建权交出，避免硬编码实现。

接口变量只认方法，不认具体类型

Go 的解耦本质来自「隐式实现」：只要结构体实现了接口定义的全部方法签名（名称、参数、返回值），就自动满足该接口，无需 implements 或 extends 声明。这使得调用方完全不感知底层类型是谁——它只依赖接口契约。

• 常见错误：试图在函数参数里写 *MyStruct 而不是 MyInterface，导致后续替换实现时必须改所有调用点
• 正确做法：把依赖抽象成接口，例如日志模块接收 Logger 而非 *FileLogger
• 效果：换用网络日志或测试用的 MockLogger 时，业务代码一行都不用动

依赖注入靠接口传参，不是 new 出来

解耦的关键动作是「把创建权交出去」。如果一个服务内部直接 new DBClient()，那它就跟数据库实现绑死了；改成接收 DBClientInterface 参数，创建逻辑就上移到调用方或工厂中。

• 典型场景：HTTP handler 依赖数据访问层，应接收 userRepo UserRepository 而非自己初始化 &MySQLUserRepo{}
• 测试时直接传入内存版 &InMemoryUserRepo{}，零依赖、秒级运行
• 容易踩的坑：接口方法设计太细（比如暴露 ExecRawSQL），反而把实现细节泄漏出去，破坏抽象

标准库 io.Reader / io.Writer 是解耦教科书

看 io.Copy 函数签名：func Copy(dst Writer, src Reader) (written int64, err error)。它不关心 dst 是文件、网络连接还是 bytes.Buffer，只要实现了 Write([]byte) (int, error) 就行。

• 你写的自定义加密 writer 只要实现 Write，就能无缝接入 io.Copy 流程
• 反过来，如果函数硬编码要求 *os.File，那你就没法用 gzip.Writer 或 http.Response.Body 替代
• 性能影响：接口调用有极小间接跳转开销，但对绝大多数 I/O 或业务逻辑可忽略；别为这点成本放弃解耦

空接口 interface{} 不是解耦，是泛化退路

interface{} 能接任何类型，但它不提供任何行为约束，无法实现真正的解耦——你拿到它之后还得用类型断言或反射才能干活，反而增加脆弱性。

• 解耦需要的是「明确的行为契约」，不是「能塞进来的任意东西」
• 例如：用 fmt.Stringer 替代 interface{} 来统一字符串输出逻辑，调用方就知道一定能调 String()
• 真实项目中过度使用 interface{} 往往是接口设计没想清楚的表现，后期很难加校验和 mock

真正难的不是写接口，而是判断哪些行为值得抽象、哪些方法签名足够稳定。一个接口一旦导出，修改它就等于破坏兼容性——所以宁可先窄后宽，从 Log(string) 开始，而不是一上来就设计带上下文、字段、级别、采样的大接口。