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)。每层只关心自己该做什么，不侵入下层类型。
立即学习“go语言免费学习笔记（深入）”；
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 时，这点比语法层面更值得警惕。
