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 接口，哪怕只改一个方法。
- 避免让 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 的链式调用里，导致可读性崩坏。
《PHP设计模式》首先介绍了设计模式，讲述了设计模式的使用及重要性，并且详细说明了应用设计模式的场合。接下来，本书通过代码示例介绍了许多设计模式。最后，本书通过全面深入的案例分析说明了如何使用设计模式来计划新的应用程序，如何采用PHP语言编写这些模式，以及如何使用书中介绍的设计模式修正和重构已有的代码块。作者采用专业的、便于使用的格式来介绍相关的概念，自学成才的编程人员与经过更多正规培训的编程人员
立即学习“go语言免费学习笔记（深入）”；
- Builder 应只负责“组装”，不负责“决策”；策略选择逻辑（如根据环境变量选重试策略）应放在 Builder 外部
- Builder 的
Build()方法不应做 I/O 或阻塞操作（比如读配置文件、连数据库），否则单元测试无法 mock - 如果 Builder 返回的对象本身还要被 Decorator 包裹，那 Builder 最好返回接口而非具体类型，否则 Decorator 得知道底层结构
复杂点往往不在模式本身，而在谁持有控制权——是 Builder 决定用哪个 Strategy，还是上层代码传进去。后者更可控，也更容易测试。
