应使用 interface{} 定义策略当算法差异大、生命周期独立且不共享状态时，如支付方式；避免将共用字段强塞入接口，宜用组合或工厂；策略应无条件判断，条件选择前置；函数类型无法携带状态和依赖，不利测试与维护；DI 与插件策略可分层处理。
什么时候该用 interface{} 定义策略而不是具体类型
当多个算法逻辑差异大、生命周期独立、且不共享内部状态时，用 interface{} 定义统一入口最稳妥。比如支付方式：PayMethod 接口只暴露 Process(amount float64) error，而 Alipay、WechatPay、CreditCard 各自实现，互不耦合。
反例是强行把带大量共用字段的结构体塞进策略接口——这时应该考虑组合或工厂封装，而非硬套策略模式。
- 策略间无共享字段或仅需极少量上下文（如
ctx context.Context） - 新增策略不需改已有代码（符合开闭原则）
- 运行时可动态切换（如根据请求头
X-Payment-Method选实现）
switch 分支太多？可能是策略没抽对粒度
常见错误：把「按用户等级打折」、「按商品类目打折」、「按促销活动打折」全塞进一个 DiscountStrategy 接口，结果每个实现里又写一堆 if 或 switch 判断条件——这说明策略边界模糊，不是策略模式用错了，是策略拆错了。
正确做法是让策略本身无条件判断，条件判断提前到选择策略的环节。例如：
立即学习“go语言免费学习笔记（深入）”；
func NewDiscountStrategy(userLevel string, category string, promoID string) DiscountStrategy {
switch {
case promoID != "" && isValidPromo(promoID):
return &PromoDiscount{ID: promoID}
case userLevel == "vip":
return &VIPDiscount{}
case category == "electronics":
return &ElectronicsDiscount{}
default:
return &DefaultDiscount{}
}
}
这样每个策略实现干净，职责单一，测试也容易覆盖。
为什么不用函数类型 func(float64) error 替代接口
函数类型轻量，适合极简场景（如日志格式化、简单校验），但策略模式真正价值在于「可携带状态 + 可依赖注入 + 可单元测试隔离」。用函数类型会丢失这些能力。
- 无法持有配置（如
StripeClient实例） - 无法在初始化时做连接池、缓存预热等操作
- 测试时难 mock（得靠闭包传依赖，易出错）
- IDE 跳转和文档提示弱，维护成本高
例如，一个需要调用外部 API 的风控策略，必须是结构体+方法，而不是裸函数：
type RiskCheckStrategy struct {
client *http.Client
timeout time.Duration
}
func (r *RiskCheckStrategy) Check(orderID string) (bool, error) {
// 使用 r.client 发起请求
}
策略注册表与 DI 容器冲突怎么办
项目用了 Wire 或 fx 做依赖注入，又想支持插件式策略注册（比如从目录自动加载 .so 策略），这两者天然矛盾：DI 要求编译期可知，插件要运行期加载。
折中方案是分层：核心策略走 DI，扩展策略走工厂 + 显式注册。避免在 DI 图里直接注入未知类型。
- 定义全局注册函数：
RegisterStrategy(name string, s Strategy) - 启动时调用已知策略的注册（如
RegisterStrategy("redis", &RedisCache{})） - 运行时通过
GetStrategy("redis")获取，不参与 DI 构建图 - 插件策略由单独模块加载，注册到同一张表，主程序无感知
关键点在于：策略实例的创建时机和生命周期必须明确分离，否则容易出现空指针或资源泄漏。
