当两个不同包中的接口拥有相同方法签名（如 do() string）时，go 无法自动区分其实现逻辑；需通过包装器（wrapper）为每个接口提供专属实现，避免单一方法体引发语义冲突。
在 Go 中，接口满足关系仅基于方法名与签名（名称 + 参数类型 + 返回类型），不依赖包路径或上下文。因此，若类型 C 同时实现了 A.Doer 和 B.Doer（二者均含 Do() string），则其唯一 Do() 方法将被两个接口共享——这在语义上存在根本性风险：A.FuncA(c) 和 B.FuncB(c) 实际调用的是同一段逻辑，而 A 与 B 对 Do() 的预期行为可能截然不同（例如：A.Do() 应返回 JSON 字符串，B.Do() 应返回 XML），硬性复用必然导致逻辑错误。
✅ 正确解法是放弃让 C 直接实现两个接口，转而为每个接口创建专用包装器类型：
package main
import (
"path/to/A"
"path/to/B"
)
type C int
// C 不再实现任何 Doer 接口，保持职责纯粹
// func (c C) Do() string { ... } // ❌ 移除此方法！
// 包装器 ADoer：专为 A.Doer 设计
type ADoer struct {
c C
}
func (a ADoer) Do() string {
// ✅ 这里实现 A 所需的特定逻辑
return "A-specific result: " + a.c.String()
}
// 包装器 BDoer：专为 B.Doer 设计
type BDoer struct {
c C
}
func (b BDoer) Do() string {
// ✅ 这里实现 B 所需的特定逻辑
return "B-specific result: " + string(rune(b.c))
}
func main() {
c := C(65) // ASCII 65 = 'A'
// 显式传递对应包装器，语义清晰、类型安全
A.FuncA(ADoer{c: c}) // 调用 ADoer.Do()
B.FuncB(BDoer{c: c}) // 调用 BDoer.Do()
}⚠️ 注意事项：
- 不可使用类型断言绕过：if _, ok := obj.(A.Doer); ok { ... } 仅用于运行时检查是否满足接口，不能改变方法行为，也无法解决“同一方法服务两套语义”的本质矛盾；
- 避免空接口 + 类型转换：interface{} + switch v.(type) 会丢失静态类型安全，违背 Go 的设计哲学；
- 包装器应轻量且无副作用：字段仅持有原始值（如 c C），方法体专注适配逻辑，不引入额外状态；
- 命名体现意图：ADoer/BDoer 比 WrapperForA 更符合 Go 命名习惯，明确表达“该类型专用于实现 A.Doer”。
总结：Go 的接口系统强调“鸭子类型”而非继承，当跨包接口出现同名方法时，语义隔离优于实现复用。通过小而专注的包装器，你既能严格满足各接口契约，又能确保每处 Do() 调用都承载正确的业务含义——这是类型安全与可维护性的双重保障。
