当两个独立包定义了同名同签名的接口（如 a.doer 和 b.doer）但语义或行为不同时，直接让一个类型实现两者会导致逻辑冲突；正确做法是使用包装器（wrapper）为每个接口提供专属实现，避免单个 `do()` 方法承担不兼容职责。
在 Go 中，接口满足性仅基于方法名和签名（即“duck typing”），而非包路径或语义。因此，若类型 C 实现了 Do() string，它将自动同时满足 A.Doer 和 B.Doer——但这恰恰是问题根源：A.FuncA(c) 和 B.FuncB(c) 都会调用同一个 C.Do() 方法，而 A 与 B 对 Do() 的预期行为可能截然不同（例如：A 要求返回 JSON 字符串，B 要求返回加密哈希），硬编码单一实现必然引发逻辑错误。
✅ 正确解法：接口专用包装器
核心思想是解耦实现——不修改原始类型 C，而是为每个目标接口创建独立的包装类型，各自封装 C 并提供符合该接口语义的 Do() 实现：
package main
import (
"path/to/A"
"path/to/B"
)
type C int
// ❌ 错误：直接实现 Do() 会导致 A 和 B 共享同一逻辑
// func (c C) Do() string { return "shared logic" }
// ✅ 正确：为 A.Doer 创建专用包装器
type DoerA struct {
c C
}
func (da DoerA) Do() string {
// 这里实现 A 所需的逻辑（例如：格式化为 A 兼容格式）
return "A-specific result from " + string(rune(da.c))
}
// ✅ 正确：为 B.Doer 创建专用包装器
type DoerB struct {
c C
}
func (db DoerB) Do() string {
// 这里实现 B 所需的逻辑（例如：执行 B 要求的计算）
return "B-specific hash of " + string(rune(db.c+100))
}
func main() {
c := C(42)
// 显式传入对应包装器，语义清晰且类型安全
A.FuncA(DoerA{c: c}) // 调用 DoerA.Do()
B.FuncB(DoerB{c: c}) // 调用 DoerB.Do()
}⚠️ 关键注意事项
- 不可依赖类型断言绕过问题：if _, ok := obj.(A.Doer) 仅能判断是否满足接口，无法解决“同一方法需不同行为”的根本矛盾。
- 避免空接口或反射：虽然 interface{} 可接收任意值，但会丢失类型安全和可读性，违背 Go 的设计哲学。
- 包装器应保持轻量：包装器仅负责适配接口契约，复杂业务逻辑仍应放在 C 或其方法中，通过组合复用。
- 文档需明确标注意图：在 DoerA 和 DoerB 的注释中说明其专用于哪个包及行为差异，防止后续维护者误用。
总结
Go 的接口设计强调“小而专注”，当跨包出现同名接口时，不应强迫一个类型承载多义行为，而应通过组合（composition）创建语义明确的适配层。包装器模式不仅解决了接口冲突，还提升了代码的可测试性（可为 DoerA/DoerB 单独编写单元测试）和可维护性（修改 A 的逻辑只需调整 DoerA，不影响 B）。这是 Go 生态中处理此类场景的标准实践。
