在 go 中实现类似面向对象的多态行为，关键在于避免在通用结构体中进行类型断言，而是让具体类型自行实现接口方法——既保持组合优势，又确保行为可扩展、可测试、无循环依赖。
在 go 中实现类似面向对象的多态行为，关键在于避免在通用结构体中进行类型断言，而是让具体类型自行实现接口方法——既保持组合优势，又确保行为可扩展、可测试、无循环依赖。
Go 作为一门强调组合而非继承的语言，其多态性并非通过“子类覆盖父类方法”实现，而是依托接口契约 + 具体类型显式实现。回到树节点场景：所有节点需支持 SetNodeState(bool)（如展开/折叠），而仅部分节点（如文档）还需联动执行 SetEditState(bool)（如显示编辑器）。若将该逻辑强行塞入通用 node 结构体中，就会陷入类型断言困境——node 本身无法知晓自己是否实现了 EditorInterface，因为嵌入不等于实现接口。
✅ 正确解法是：*让具体类型（如 `document）完整实现NodeInterface`，并在其中调用嵌入字段的方法 + 补充特有逻辑**。如下所示：
type document struct {
*node
visible bool
content string
}
// 显式实现 NodeInterface —— 这是多态的核心
func (d *document) SetNodeState(state bool) {
d.node.SetNodeState(state) // 复用通用逻辑
d.SetEditState(state) // 触发特有行为
}
func (d *document) SetEditState(state bool) {
d.visible = state
}
此时 folder 可直接复用嵌入的 *node.SetNodeState（无需重写），而 document 则在重写中自然完成状态联动。这种设计完全符合 Go 的接口哲学：
- ✅ 零运行时类型断言：无 n.(EditorInterface) 等脆弱检查；
- ✅ 清晰的责任边界：node 只管通用状态，document 决定如何响应状态变更；
- ✅ 天然支持包解耦：node 和 NodeInterface 可置于 tree 包，document/folder 在 tree/nodes 子包中实现，避免循环依赖；
- ✅ 易于测试与扩展：新增 imageDocument 类型只需实现 SetNodeState，无需修改 node 源码。
⚠️ 注意事项：
- 嵌入（embedding）仅提供字段与方法的自动代理，但不会自动实现接口——必须由最终类型显式声明方法签名；
- 避免在通用结构体中添加“为多态而设”的冗余字段（如 self NodeInterface），这违背组合初衷；
- 若某行为确实跨多种类型且难以归入单个类型（如通用遍历、序列化），则采用函数式风格：func Walk(n NodeInterface, fn func(NodeInterface))，这是 Go 标准库（如 io, net/http）推崇的惯用法。
总结：Go 的多态不是“让基类猜子类能做什么”，而是“让每个具体类型明确承诺它能做什么”。通过接口定义契约、结构体嵌入复用通用能力、具体类型重写实现差异化行为——三者协同，即可写出清晰、健壮、地道的 Go 多态代码。
