该用 interface{} 定义策略时，应优先使用具体接口（如 PaymentStrategy）而非 interface{}；仅当策略类型完全未知且需泛型兼容时才用 interface{}，但会丢失类型安全和方法约束。
什么时候该用 interface{} 定义策略，而不是具体结构体
当多个算法逻辑差异大、运行时才决定使用哪一种，且不希望调用方感知具体实现时，必须用接口抽象策略。比如支付方式：微信支付、支付宝、银行卡，它们的签名流程、回调验签、错误重试机制完全不同，但对外都提供 Pay(order *Order) error 方法。
常见错误是提前用具体结构体（如 WechatPay）作为参数类型，导致新增支付渠道时要改所有调用点。正确做法是定义统一接口：
type PaymentStrategy interface {
Pay(*Order) error
Refund(*RefundReq) error
}
这样新增策略只需实现接口，不侵入原有业务逻辑。
map[string]PaymentStrategy 注册表是否安全
注册表本身不是问题，问题在于并发读写和初始化时机。如果在 init() 函数里静态注册，或通过单例 + sync.Once 初始化，是安全的；但如果在 HTTP handler 中动态注册，又没加锁，就会出现竞态。
立即学习“go语言免费学习笔记（深入）”；
建议做法：
- 启动时一次性注册全部策略，避免运行时修改
- 用
sync.RWMutex包裹读写操作（即使只读也建议用RLock，为扩展留余地） - 键名统一用常量，避免拼写错误：
const StrategyAlipay = "alipay"
策略内部需要共享配置时怎么传参
不要把配置塞进策略结构体字段再靠构造函数注入——这会让策略对象变成“有状态”的，难以测试和复用。更合理的方式是让策略方法接收上下文和配置：
func (s *AlipayStrategy) Pay(ctx context.Context, order *Order, cfg AlipayConfig) error {
// 使用 cfg.SignKey、cfg.GatewayURL 等
return s.client.DoPay(ctx, order, cfg)
}
这样同一实例可复用不同配置，也方便单元测试中传入 mock 配置。若配置极多，可封装为 struct 传入，但别让它成为策略对象的生命周期依赖。
为什么不用 switch 直接分支而要用策略模式
表面看，switch strategyName { case "wechat": ... } 更轻量。但它在三处失效：
- 新增策略要改主逻辑（违反开闭原则）
- 无法对策略做统一装饰（如统一加日志、熔断、超时控制）
- 测试困难：每个分支得单独写 case 覆盖，而接口实现可单独单元测试
策略模式真正的价值不在“多态”，而在把变化点隔离成可插拔的组件。Golang 没有类继承，但靠接口 + 组合 + 依赖注入，一样能达成解耦目标。
最容易被忽略的是策略的生命周期管理——比如某个策略依赖外部 HTTP 客户端，它该由谁创建、复用、关闭？通常应由策略工厂统一管理，而不是让每个策略自己 new client。
