Go中结构体嵌入接口仅为声明可替换字段，不提升方法；必须显式初始化，且字段名需导出；其核心价值是运行时依赖注入与动态替换实现。
Struct里嵌入接口不是为了“继承方法”，而是为了字段可替换
Go里结构体嵌入接口，和嵌入结构体有本质区别：它不提升任何方法，也不带来字段访问能力，只是把一个接口类型声明为结构体的字段。真正价值在于运行时动态替换实现——比如测试时用 mock，线上用 real client。
常见错误现象：u.Logger.Write("msg") 编译失败，提示 u.Logger undefined，其实是忘了给字段赋值；或者运行时报 panic: interface conversion: interface {} is nil，说明嵌入的接口字段没初始化就调用了方法。
- 嵌入接口必须显式赋值，Go 不会自动初始化为 nil-safe 的空实现
- 字段名必须导出（首字母大写），否则外部无法赋值或调用
- 接口字段不能是匿名字段（即不能省略字段名），否则语法错误
嵌入接口时，指针接收者 vs 值接收者影响 nil 判断
结构体方法接收者类型决定了该结构体实例能否安全赋给嵌入的接口字段。如果接口方法约定用指针接收者，而你传的是值类型实例，Go 会静默转换为指针——但若该值是零值（如 Logger{}），取地址后仍是有效指针，调用方法可能 panic。
典型场景：日志模块 type Logger interface { Info(string) }，实现类 func (l *ConsoleLogger) Info(msg string)。这时必须传 &ConsoleLogger{}，不能传 ConsoleLogger{}，否则 l 在方法内为 nil，l.writer.Write() 直接 panic。
立即学习“go语言免费学习笔记（深入）”；
- 接口定义的方法接收者类型，应与实际实现保持一致（统一用指针，或统一用值）
- 构造函数中应确保返回非 nil 实例，例如
return &ConsoleLogger{writer: os.Stdout} - 测试时可用
nil值模拟故障路径，但需在方法内做if l == nil判断
嵌入接口 + 构造函数 = 可控依赖注入
直接在结构体里写死依赖（如 db *sql.DB）会导致单元测试困难、模块耦合高。用接口嵌入配合构造函数，能把依赖控制权交给调用方。
示例：type Service struct { repo UserRepo }，其中 UserRepo 是接口。这样 NewService(&mockRepo) 和 NewService(&realRepo) 就能共用同一套业务逻辑。
- 构造函数参数应接收接口，而非具体结构体，避免暴露实现细节
- 不要在构造函数里 new 出具体实现（如
repo: &mysqlRepo{}），那会破坏解耦 - 如果多个依赖存在顺序依赖（如
cache需要logger），应在构造函数参数中显式传递，而非让结构体自己 new
嵌入接口不等于“组合接口”，别和接口嵌套混淆
结构体嵌入接口（type A struct { B Interface }）和接口嵌套（type C interface { B; D }）是两回事。前者是数据结构设计，后者是行为契约扩展。有人试图用嵌入接口来“复用接口定义”，结果发现字段不能当接口用，编译不过。
错误写法：type Handler struct { http.Handler } 想让 Handler 自动拥有 ServeHTTP 方法——不行，这只会声明一个叫 Handler 的字段，不提升任何方法，也不能直接调用 h.ServeHTTP()。
- 想让结构体具备某接口能力，必须自己实现该接口全部方法，或通过嵌入实现了该接口的结构体（不是接口）
- 接口嵌套用于定义更大契约，如
io.ReadWriter嵌套io.Reader和io.Writer - 嵌入接口唯一作用是预留插槽，填什么、何时填、怎么填，全由使用者决定
真正容易被忽略的点是：嵌入接口字段的生命周期完全独立于宿主结构体。它可能被多次重置、跨 goroutine 共享、甚至为 nil——这些都得在方法里主动防御，而不是假设它“一定可用”。
