策略接口应聚焦可替换行为本质，仅含1～2个核心方法，输入输出用结构体封装；注册宜用字段或标签驱动，避免硬编码map；执行时只传必要数据，上下文仅控超时；无状态策略可复用单例；测试需覆盖边界与错误路径。
策略接口定义要聚焦行为契约，别带具体实现细节
Go 里没有抽象类，策略模式靠接口实现。关键不是“定义一个叫 Strategy 的接口”，而是抓住业务中**可替换的行为本质**。比如订单折扣逻辑，真正该抽象的是 CalculateDiscount 这个动作，而不是“满减”“会员折”这些名词。
常见错误是把策略接口设计得过宽或过窄：
- 过宽：接口含 Init、Validate、Log 等非核心方法，导致所有策略都得空实现
- 过窄：只定义 Apply()，但不同策略需要不同参数（比如有的要用户等级，有的要订单金额区间），结果调用方要不断类型断言或传 map
推荐做法：
- 接口只保留 1～2 个核心方法，如 Execute(ctx context.Context, input interface{}) (interface{}, error)
- 输入输出用结构体封装，字段按实际策略需要定义，避免泛型或 interface{} 滥用
- 若策略初始化差异大（如有的需 Redis 客户端，有的只需配置），用工厂函数或选项模式提前注入依赖，而非塞进接口
策略注册与查找别硬编码 map，优先用结构体字段或标签驱动
很多人一上来就写 map[string]Strategy，然后在 switch 或 if 链里手动注册。这会导致新增策略时必须改注册代码，违反开闭原则。
更稳妥的做法：
- 把策略类型映射关系藏在结构体字段里，比如订单结构体带 DiscountType string 字段，运行时查表或反射匹配
- 或用 Go 的 //go:generate + 注册标签（如 // @strategy name:"vip"）自动生成注册表，避免手误
- 若策略极少变动（如全年就 3 种折扣），直接用 switch discountType 也比 map 查找更清晰——别为了设计模式而设计模式
注意：别在 init() 函数里全局注册策略，容易引发 init 循环或测试难 mock；策略实例应由调用方按需构造或通过依赖注入容器获取。
策略执行时的上下文传递要克制，避免把整个 request 或 service 塞进去
策略本该是无状态、专注单一计算的。但实践中常看到 Execute(ctx, *http.Request, *UserService, *OrderRepo) 这种签名，导致策略重度耦合 HTTP 层和数据层。
立即学习“go语言免费学习笔记（深入）”；
正确做法：
- 执行前由上层完成数据组装，只传策略真正需要的原始值，例如：discountInput{Amount: 299.0, Level: "gold", CouponCode: "SUMMER20"}
- 若策略真需调外部服务（如查用户积分），应在创建策略实例时通过构造函数注入 client，而非每次执行都传
- Context 仅用于超时和取消控制，不用于传业务数据；业务数据走显式参数
性能提示：频繁创建策略实例（如每笔订单新建一个）可能带来 GC 压力。对无状态策略，可复用单例；有状态的（如带缓存）才按需 new。
单元测试策略实现时，重点验证边界条件和错误路径
策略类代码看似简单，但最容易出问题的是边界场景：负数金额、空优惠码、过期时间、并发修改同一用户等级等。
写测试时建议：
- 每个策略实现单独测试文件，不和主流程混在一起
- 用 table-driven 方式覆盖典型输入+预期输出，例如：{input: discountInput{Amount: 0}, want: 0}、{input: discountInput{CouponCode: ""}, wantErr: true}
- 对依赖外部服务的策略（如调用风控 API），用 interface + mock 实现隔离，别用真实 HTTP client
- 别忘了测试策略未被正确选择时的行为（比如传了未知 type，是否 panic 还是返回默认策略或 error）
一个容易被忽略的点：策略组合使用时（如先用会员折扣，再叠加优惠券），组合逻辑本身也是策略，应单独抽象和测试，而不是堆在业务 handler 里。
