Go 中实现多态行为的正确方式：嵌入与接口方法重写

聊到 Go 语言中的多态，很多人第一反应是“这语言没有继承，怎么玩多态”。其实，Go 通过**接口 + 嵌入 + 方法重写**这套组合拳，完全可以优雅地模拟出分层行为，而且比传统面向对象更轻量、更可控。核心原则很明确：**通用状态与基础逻辑封装在嵌入结构中，类型特有的行为（比如 document 的可见性控制）由具体类型自己实现接口方法**。

在 Go 中实现类似面向对象的多态，关键在于合理使用结构体嵌入和接口方法重写——而非依赖类型断言或反向依赖；通用逻辑放在嵌入结构中，类型特有行为由具体结构体自行实现并组合调用。

先看一个典型的场景：树节点。假设有一个 `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` 存在，一旦有新的子类型出现，就得回头修改 `node`。 - **接口只应聚焦契约，而非暴露实现细节**。`NodeInterface` 只声明 `SetNodeState`，不暴露字段或内部结构，这样调用方只需关心行为，不需要知道内部怎么存数据。 - **优先用组合，而不是继承思维**。Go 的嵌入本质是“has-a”关系——`document` 拥有一个 `node`，而不是“是”一个 `node`。这个区别决定了代码的灵活性和解耦能力。 - **包设计要留意依赖方向**。如果要把 `node` 提取为公共类型，一定要确保 `document`、`folder` 等具体类型只依赖它，而不是反过来——这是 Go 包解耦的关键。 总结一下：Go 的多态不是靠运行时类型检查来驱动的，而是靠**编译期接口满足 + 显式方法重写 + 组合调用**来实现的。它更轻量、更可控，也更符合 Go “少即是多”的哲学。当你需要“不同类型的节点对同一操作做出不同响应”时，请让每种类型自己定义那个响应，而不是让通用结构去猜测它面对的是谁。