当两个不同包中的接口拥有相同方法签名（如 do() string）时，go 无法自动区分其语义差异；直接让一个类型实现两者会导致逻辑冲突，正确做法是通过包装器（wrapper）为每个接口提供专属实现。
在 Go 中，接口满足性仅基于方法名与签名完全一致（即“鸭子类型”），不关心包路径或语义意图。因此，若 A.Doer 和 B.Doer 均定义为 Do() string，则任意实现了 Do() string 的类型（如 type C int）会同时满足二者。但问题核心在于：A.Doer.Do() 和 B.Doer.Do() 在业务上可能要求完全不同的行为逻辑——例如前者返回格式化日志，后者返回序列化 ID。此时，若 C.Do() 只有一份实现，必然导致 A.FuncA(c) 与 B.FuncB(c) 调用同一逻辑，引发不可控的副作用或错误。
✅ 正确解法：使用语义明确的包装器
避免在基础类型 C 上直接实现 Do()，而是为每个接口创建专用包装器，将逻辑解耦：
package main
import (
"path/to/A"
"path/to/B"
)
type C int
// 不再为 C 实现 Do() —— 彻底消除歧义
// func (c C) Do() string { ... } // ❌ 移除！
// 包装器 ADoer：专为 A.Doer 设计，封装 C 并实现 A 语义
type ADoer struct {
c C
}
func (a ADoer) Do() string {
// ✅ 这里实现 A 所需的逻辑（如：返回带时间戳的日志）
return "A-Log: " + a.c.String()
}
// 包装器 BDoer：专为 B.Doer 设计，封装同一 C 实例
type BDoer struct {
c C
}
func (b BDoer) Do() string {
// ✅ 这里实现 B 所需的逻辑（如：返回十六进制编码 ID）
return "B-ID:" + fmt.Sprintf("%x", int(b.c))
}
func main() {
c := C(42)
// 显式传递语义正确的包装器
A.FuncA(ADoer{c}) // → 调用 ADoer.Do()
B.FuncB(BDoer{c}) // → 调用 BDoer.Do()
// ✅ 类型安全：无法误传 ADoer 给 B.FuncB（编译报错）
// B.FuncB(ADoer{c}) // ❌ compile error: cannot use ADoer as B.Doer
}⚠️ 注意事项与最佳实践
- 零分配优化（可选）：若性能敏感，可将包装器定义为指针类型并实现指针接收者方法，避免值拷贝；但需确保 C 本身轻量。
- 避免类型断言滥用：if _, ok := obj.(A.Doer); ok { ... } 仅用于运行时检查，不能解决逻辑歧义问题——它只是确认满足性，而非赋予不同行为。
- 文档即契约：在 ADoer 和 BDoer 的注释中明确说明各自 Do() 的业务职责（如 “ADoer.Do returns audit-trail formatted string”），强化团队理解。
- 考虑重构接口（长期）：若跨项目频繁出现此类冲突，建议推动上游包将接口方法重命名为更具领域语义的名称（如 A.Do() → A.DoAudit()，B.Do() → B.DoExport()），从根本上消除歧义。
通过包装器模式，你不仅解决了同名方法的语义隔离问题，还提升了代码可读性与可维护性——每个类型只承担单一职责，调用方也必须显式选择符合上下文的实现，彻底规避隐式行为污染。
