17370845950

Go中无装饰器语法，但可通过结构体嵌入（尤其指针嵌入）模拟装饰器模式：嵌入原类型并重写方法以增强行为；需统一接口、避免nil指针、注意初始化顺序与生命周期。

Go 里没有装饰器语法，但结构体嵌入能模拟行为增强

Go 语言本身不支持 Python 那种 @decorator 语法，也没有 Java 的注解 + AOP 框架。所谓“装饰器模式”在 Go 中本质是：**用组合代替继承，通过嵌入（embedding）已有类型，再覆盖或扩展其方法**。关键不是名字，而是能否在不修改原类型的前提下，动态添加职责（比如加日志、重试、熔断）。

嵌入匿名字段是核心，方法集规则决定能否“透明装饰”

要让装饰行为对调用方无感，必须满足：被装饰类型的方法必须出现在装饰器的可导出方法集中。这取决于嵌入方式：

• 嵌入 struct{} 或 *struct{} —— 前者嵌入值类型，后者嵌入指针类型；方法集差异直接影响能否调用指针接收者方法
• 若原类型 Foo 只有指针接收者方法（如 (*Foo).Do()），则必须嵌入 *Foo，否则 DecoratedFoo.Do() 编译失败
• 嵌入后，若想拦截/增强某方法，需在装饰器中定义同名方法（显式覆盖），内部通常仍调用 d.Foo.Do()

type Foo struct{}

func (*Foo) Do() string { return "original" }

type LoggingFoo struct {
    *Foo // 必须是指针嵌入，否则无法调用 *Foo.Do()
}

func (l *LoggingFoo) Do() string {
    fmt.Println("before Do")
    result := l.Foo.Do()
    fmt.Println("after Do")
    return result
}

装饰器链式调用需手动拼接，不能自动叠加

Python 装饰器可以堆叠写成 @log @retry @cache，Go 没有这种语法糖。多个装饰逻辑只能靠手动嵌套构造：

• new(RetryFoo).Wrap(new(CacheFoo).Wrap(new(LoggingFoo).Wrap(&RealService{}))) 这类写法易错且难读
• 更实际的做法是定义统一接口（如 Service interface{ Do() string }），所有装饰器和原始实现都实现它
• 构造时按需组合：先包一层 CacheService，再包一层 RetryService，最后赋给接口变量
• 注意：每层装饰器都应持有下一层的接口引用（不是具体类型），避免强耦合

type Service interface {
    Do() string
}

type CacheService struct {
    next Service // 接口，非具体类型
}

func (c *CacheService) Do() string {
    // 先查缓存...
    return c.next.Do() // 调用下一层
}

别忽略零值与初始化顺序问题

结构体嵌入后，如果装饰器字段未显式初始化，会触发零值行为，常见陷阱：

立即学习“go语言免费学习笔记（深入）”；

• 嵌入的是指针类型（如 *Foo），但没赋值就调用其方法 → panic: nil pointer dereference
• 嵌入的是值类型（如 Foo），但 Foo 自身含不可复制字段（如 sync.Mutex）→ 编译错误
• 装饰器构造函数未校验嵌入字段是否为 nil，导致运行时崩溃
• 建议：装饰器构造函数强制传入依赖项，并做非空检查；或用选项模式（functional options）延迟配置

真正难的不是写一个装饰器，而是确保整条链上每个环节都正确处理了嵌入字段生命周期、错误传播、上下文传递——这些细节不会报编译错误，但会在压测时突然暴露。