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{} 能接任何类型，但它不提供任何行为约束，无法实现真正的解耦——你拿到它之后还得用类型断言或反射才能干活，反而增加脆弱性。
立即学习“go语言免费学习笔记（深入）”；
- 解耦需要的是「明确的行为契约」，不是「能塞进来的任意东西」
- 例如：用
fmt.Stringer替代interface{}来统一字符串输出逻辑，调用方就知道一定能调String() - 真实项目中过度使用
interface{}往往是接口设计没想清楚的表现，后期很难加校验和 mock
Log(string) 开始，而不是一上来就设计带上下文、字段、级别、采样的大接口。 
