让新结构体满足旧 interface 的关键是通过适配器模式精准转发调用，不篡改语义、不新增逻辑，严格遵循方法集规则和接收器类型匹配，并避免导出内部字段以维护封装性。
Go 里怎么让新结构体满足旧 interface？
直接实现旧 interface 的所有方法，但别硬凑空实现——适配器不是补丁，是桥。关键在「只转发、不改造」：新类型只负责把调用转给内部持有的旧对象或新逻辑，自己不掺和业务判断。
常见错误是把适配器写成「增强版旧接口」，比如在 Read 方法里偷偷加日志或重试——这会让调用方误以为仍是纯读操作，破坏契约。适配器的职责边界必须清晰：输入是什么，输出就该是什么，中间不埋逻辑。
- 旧 interface 定义在第三方包里（如
io.Reader），你不能改它，只能适配 - 新逻辑封装在 struct 里，但方法签名和旧 interface 不匹配（比如多一个
ctx context.Context参数） - 你想复用已有实现，但它的 receiver 是指针而旧 interface 要求值接收（或反之），导致无法赋值
func (a *Adapter) Read(p []byte) (n int, err error) 怎么处理 ctx？
Go 没有重载，也不能改旧方法签名。所以带 context.Context 的新逻辑，必须在适配器里「兜住」：要么用 context.Background() 填充，要么把 ctx 存在 adapter 字段里，靠外部初始化时传入——但后者意味着这个 adapter 实例不再无状态，要注意并发安全。
性能上，每次 Read 都新建 context（比如用 context.WithTimeout）会分配内存；如果只是透传，建议初始化时固定一个 ctx 字段，避免 runtime 分配。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type ReaderAdapter struct {
r io.Reader
ctx context.Context // 外部注入，非每次调用新建
}
func (a *ReaderAdapter) Read(p []byte) (int, error) {
// 注意：这里没用 a.ctx 做 cancel 控制，因为 Read 本身不接受 ctx
// 真正需要 ctx 的地方，得另起方法，或换用 io.ReaderWithContext（Go 1.22+）
return a.r.Read(p)
}
为什么嵌入 struct 后还是报 “does not implement xxx”？
嵌入（embedding）只是语法糖，不是自动实现。编译器只检查方法集是否完整，不看有没有嵌入。典型坑是：嵌入的是值类型，但 interface 要求指针方法；或者嵌入的是指针，但原方法是值接收器。
Go 的方法集规则很严格：只有 *T 能调用 (*T).M 和 (T).M；而 T 只能调用 (T).M。所以如果你嵌入 http.Client（它所有方法都是指针接收器），那你的 struct 必须用 *http.Client 嵌入，否则无法满足 Doer 这类 interface。
- 检查被嵌入类型的接收器类型：
go doc http.Client.Do看它是(c *Client) Do(...)还是(c Client) Do(...) - 确保你的 struct 字段类型与接收器类型一致：要满足指针方法，字段就得是指针
- 别依赖 IDE 自动补全——它可能帮你嵌入了
http.Client，但实际需要的是*http.Client
适配器要不要导出内部字段？
不要。导出字段（首字母大写）等于暴露实现细节，调用方可能绕过适配逻辑直接操作底层对象，导致行为不一致。比如你写了 type LogWriterAdapter struct { Writer io.Writer }，别人直接调 adapter.Writer.Write(...)，就跳过了你的日志记录逻辑。
真正需要扩展能力的地方，应该提供明确的新方法（如 SetLogger(*log.Logger)），而不是开放字段。兼容性代价小，维护边界清楚。
另外，如果内部字段是第三方类型（如 *sql.DB），导出它还会让你的包强耦合到那个版本——万一对方加个方法，你就被动实现了不该实现的 interface。
Close() 要求幂等，而你的新资源关闭逻辑天然不幂等——这时候该修新逻辑，而不是在适配器里加锁模拟幂等。 
