在 go 中实现类似面向对象的多态，关键在于合理使用结构体嵌入和接口方法重写——而非依赖类型断言或反向依赖；通用逻辑放在嵌入结构中，类型特有行为由具体结构体自行实现并组合调用。
在 go 中实现类似面向对象的多态，关键在于合理使用结构体嵌入和接口方法重写——而非依赖类型断言或反向依赖；通用逻辑放在嵌入结构中，类型特有行为由具体结构体自行实现并组合调用。
Go 并不提供传统意义上的继承或多态机制，但通过接口 + 嵌入 + 方法重写可以优雅地模拟分层行为。核心原则是：通用状态与基础行为封装在嵌入结构中，而类型专属逻辑（如 document 的可见性控制）必须由具体类型显式实现其接口方法。
以树节点为例，node 结构体承载所有节点共有的字段（如 open、children）和基础方法（如 SetNodeState），但它不应感知子类型的存在——即不能在 node.SetNodeState 中做 n.(EditorInterface) 类型断言。否则会破坏封装性，并导致循环依赖风险（如 node 依赖 document，而 document 又嵌入 node）。
正确的做法是：让具体类型（如 *document）实现 NodeInterface，并在其实现中组合调用嵌入结构的方法 + 自身扩展逻辑：
type document struct {
*node
visible bool
content string
}
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 则在保持接口一致性的同时，自然注入编辑状态联动逻辑。测试代码可安全断言类型并验证行为：
n := getTestNode() // 返回 NodeInterface，实际为 *document
n.SetNodeState(true)
if !n.(*document).visible { // 显式类型断言仅用于测试/边界场景
t.Error("document is not visible")
}⚠️ 注意事项：
- 避免在嵌入结构中进行接口类型断言：这违背了“基类不应了解子类”的设计准则，也使 node 包无法独立于 document 存在；
- 接口应聚焦契约，而非实现细节：NodeInterface 只声明 SetNodeState，不暴露字段或内部结构；
- 优先组合，而非继承思维：Go 的嵌入是“has-a”而非“is-a”，document 拥有一个 node，而非“是”一个 node；
- 包设计需注意依赖方向：若将 node 提取为公共类型，应确保 document/folder 等具体类型只依赖它，而非反之——这是 Go 包解耦的关键。
总结：Go 的多态不是靠运行时类型检查驱动，而是靠编译期接口满足 + 显式方法重写 + 组合调用实现。它更轻量、更可控，也更符合 Go “少即是多”的哲学——当你需要“不同类型的节点对同一操作做出不同响应”时，请让每种类型自己定义那个响应，而不是让通用结构去猜测它面对的是谁。
