Factory 和 Strategy 应在需动态创建算法实例且算法内部依赖可替换行为时组合使用，如支付模块根据 payType 创建不同策略并注入签名器等依赖。
什么时候该把 Factory 和 Strategy 一起用
当你的业务逻辑需要根据运行时参数动态创建不同算法实现，且这些算法本身又需要封装可替换的行为时，Factory + Strategy 是最自然的组合。比如支付模块：用户选择微信支付或支付宝，系统要创建对应的支付策略实例，而每个策略内部还可能依赖不同的签名生成器、回调处理器。
-
Factory负责根据payType字符串返回具体的PaymentStrategy实现 -
Strategy接口定义Pay()和Refund()，但不关心如何序列化请求或验签 - 真正解耦的关键在于：Factory 创建 Strategy 时，可以传入其他依赖（比如一个
Signer），而这个Signer本身也可以是另一个 Strategy 或由 Builder 构建
type PaymentStrategy interface {
Pay(order *Order) error
}
type WechatPayStrategy struct {
signer Signer // 可替换的签名策略
}
func NewWechatPayStrategy(signer Signer) *WechatPayStrategy {
return &WechatPayStrategy{signer: signer}
}
func PaymentStrategyFactory(payType string) PaymentStrategy {
switch payType {
case "wechat":
return NewWechatPayStrategy(&WechatSHA256Signer{})
case "alipay":
return NewAlipayStrategy(&AlipayRSA2Signer{})
default:
panic("unknown pay type")
}
}
为什么 Observer 不该直接嵌套在 Singleton 里
常见错误是把事件监听器注册逻辑塞进单例的 GetInstance() 方法里，导致每次获取实例都重复绑定、内存泄漏、测试困难。Singleton 只应负责“唯一实例”的生命周期；Observer 关系必须可手动管理。
- 单例对象（如
Logger）暴露Subscribe()和Unsubscribe()方法，而不是自动绑定 - 订阅者应在初始化阶段显式调用，比如在
main()或模块init()中完成 - 若用
sync.Once初始化单例，切勿在其中调用任何可能阻塞或依赖外部状态的 Observer 注册逻辑
var loggerInstance *Logger
var loggerOnce sync.Once
func GetLogger() *Logger {
loggerOnce.Do(func() {
loggerInstance = &Logger{
subscribers: make(map[int]func(string))，
}
})
return loggerInstance
}
// 正确：由使用者决定何时订阅
func main() {
log := GetLogger()
log.Subscribe(1, func(msg string) { fmt.Println("[DEBUG]", msg) })
}
Decorator + Interface 嵌套容易踩的坑
Go 没有继承，靠接口组合实现 Decorator，但过度嵌套会导致方法爆炸和 nil panic。典型场景是给 HTTP handler 加日志、熔断、指标上报——每层 Decorator 都要完整实现 http.Handler 接口，哪怕只改一个方法。
ImageMagick 批处理处理器
下载
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
- 避免让 Decorator 实现整个接口；优先用函数包装器（
func(http.Handler) http.Handler）而非结构体 - 如果必须用结构体 Decorator，确保其字段（如
next http.Handler）在构造时非 nil，并在ServeHTTP开头加if d.next == nil { panic(...) } - 多个 Decorator 组合时，顺序敏感：日志 Decorator 包裹熔断 Decorator，和反过来，行为完全不同
func WithMetrics(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// 记录指标
next.ServeHTTP(w, r) // 注意：这里假设 next 不为 nil
})
}
func main() {
h := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("ok"))
})
// 正确顺序：指标 → 熔断 → 日志 → 原始 handler
http.ListenAndServe(":8080", WithMetrics(WithCircuitBreaker(WithLogging(h))))
}
Builder 在组合模式中不是万能的
Builder 适合构建复杂对象，但一旦和其他模式混用，容易变成“配置黑洞”。比如用 Builder 构建一个带多种 Strategy 的 Service 实例，最后却把所有策略类型、超时、重试次数全塞进 Builder 的链式调用里，导致可读性崩坏。
立即学习“go语言免费学习笔记（深入）”；
- Builder 应只负责“组装”，不负责“决策”；策略选择逻辑（如根据环境变量选重试策略）应放在 Builder 外部
- Builder 的
Build()方法不应做 I/O 或阻塞操作（比如读配置文件、连数据库），否则单元测试无法 mock - 如果 Builder 返回的对象本身还要被 Decorator 包裹，那 Builder 最好返回接口而非具体类型，否则 Decorator 得知道底层结构
复杂点往往不在模式本身，而在谁持有控制权——是 Builder 决定用哪个 Strategy，还是上层代码传进去。后者更可控，也更容易测试。
