17370845950

Go中装饰器通过接口+嵌入实现行为增强，非继承；装饰者与被装饰者同实现接口，仅重写需增强方法并委托调用；需显式处理资源释放，不可依赖自动传播。

Go 里没有装饰器语法，但可以用组合+接口模拟行为增强

Go 不支持类继承，也没有 Python 那种 @decorator 语法，所谓“装饰器模式”在 Go 中本质是**通过嵌入（embedding）+ 接口实现动态行为叠加**。它不替代“继承关系”，而是绕过继承——用组合表达“拥有什么能力”，而非“是什么类型”。

常见误操作是强行写个 Decorator 结构体去包装另一个结构体，再重复实现所有方法。这既冗余又脆弱。正确做法是让被装饰者和装饰者都实现同一接口，装饰者只重写需要增强的方法，其余方法直接委托给内嵌字段。

• 装饰逻辑必须基于接口，不能基于具体类型
• 被装饰对象应作为匿名字段嵌入装饰器结构体中
• 装饰器方法中调用 decorator.embedded.Method() 是显式委托，不是自动继承
• 如果装饰器需添加新方法（非接口定义），调用方必须知道具体类型，会破坏接口抽象

用 io.Reader 和 io.MultiReader 理解真实装饰链

标准库就是最佳示例：io.MultiReader 并不继承某个 Reader，而是实现 io.Reader 接口，并把读取逻辑分发给多个 io.Reader 实例。类似地，gzip.NewReader 返回一个实现了 io.Reader 的新类型，内部持有原始 io.Reader，并在 Read() 中加解压逻辑。

这种模式天然支持多层装饰：比如 gzip.NewReader(bufferedReader) → bufferedReader 本身又是 bufio.NewReader(file)。每层只关心自己该做什么，不侵入下层类型。

type LoggingReader struct {
    io.Reader
    logger *log.Logger
}

func (lr *LoggingReader) Read(p []byte) (n int, err error) {
    lr.logger.Printf("Read start, len=%d", len(p))
    n, err = lr.Reader.Read(p) // 委托给嵌入字段
    lr.logger.Printf("Read done, n=%d, err=%v", n, err)
    return
}

为什么不能用嵌入替代继承的“is-a”语义

嵌入提供的是“has-a + 可被提升调用”的便利，不是类型层级上的子类化。例如：

• type Dog struct { Animal } 中 Dog 可调用 Animal.Eat()，但 func feed(a Animal) 不能接收 Dog 值——除非 Dog 显式实现 Animal 接口
• 真正可替代继承的，是让 Dog 和 Cat 都实现 Animal 接口，而 LoggingDog 再实现同一接口并嵌入 Dog
• 如果依赖反射或类型断言判断 “是不是某种父类”，说明设计已偏离 Go 的接口哲学

装饰器叠加时要注意生命周期和资源释放

多个装饰器嵌套时（如 LoggingReader → TimeoutReader → file），Close() 或其他清理方法不会自动传播。必须显式实现，并按逆序调用各层资源关闭逻辑。

例如，若你封装了一个带缓存的 http.RoundTripper 装饰器，它持有 http.Transport，就不能只靠嵌入自动获得 CloseIdleConnections()；得自己暴露方法并转发。

• 不要假设嵌入字段的 Close() 会被自动调用
• 装饰器的 Close() 应先处理自身资源，再调用嵌入字段的 Close()
• 若嵌入字段无 Close() 方法，装饰器也不应凭空添加——这违反接口契约

复杂装饰链容易漏掉某一层的清理，尤其涉及文件、网络连接、goroutine 时，这点比语法层面更值得警惕。