策略模式用于隔离可变业务规则，需定义精简的ActivityStrategy接口，各策略类无状态、只专注计算，上下文负责传入已实例化策略并管理其生命周期，新增活动只需三步且不修改旧代码。
Strategy 接口不是装饰器，也不是工厂，它只是让不同活动逻辑彼此隔离、互不污染的最小契约。只要业务活动规则在变（比如「满300减50」、「第二件半价」、「新客首单立减20」），就该用策略模式，而不是往 if-else 里硬塞新分支。
定义统一的 ActivityStrategy 接口
所有活动类型必须实现同一套方法签名，否则上下文无法无差别调用。接口越薄越好，只保留真正需要外部传入和返回的核心参数。
常见错误是把「订单号」「用户ID」这类上下文信息也塞进接口方法——它们应该由上下文类持有并透传，策略本身只关心「怎么算」。
-
calculate($originalPrice, $quantity)：必须返回最终应付金额或折扣额，不建议返回数组或对象 - 避免在接口中定义
validate()或log()这类辅助方法，它们属于具体策略内部职责 - 如果某些策略需要额外配置（如阈值、比例），通过构造函数注入，而非方法参数
写具体策略类时注意运行时隔离
每个策略类只做一件事：给定输入，返回确定结果。不要在 ManJianStrategy 里查数据库、调第三方 API 或写日志——这些行为会拖慢主流程，且让策略失去可测试性。
立即学习“PHP免费学习笔记（深入）”；
典型陷阱是把「判断是否满足满减条件」和「执行减扣计算」混在一个方法里。应拆成两步：先由上下文决定是否启用该策略（比如检查订单金额 ≥ 300），再调用 calculate()。
-
DaZheStrategy只管乘以 0.5，不检查用户是否 VIP —— 那是权限服务的事 -
NewUserStrategy构造时接收$discountAmount = 20，不从配置中心实时拉取 - 所有策略类必须是无状态的（stateless），不能依赖
$this->cache或静态变量缓存中间结果
上下文类别暴露策略设置细节
ActivityContext 的作用不是“选策略”，而是“用策略”。它不该提供 setStrategyByType($type) 这种松散方法，而应由调用方明确传入已实例化的策略对象。
容易被忽略的一点：策略对象的生命周期管理。如果策略类依赖外部服务（如 Redis 客户端），别在每次调用 calculate() 时 new 一个，而应在上下文初始化时注入，或由 DI 容器统一管理。
- 拒绝在
ActivityContext->__construct()里根据配置自动 new 策略——这会让单元测试无法 mock - 不要让上下文持有策略工厂引用，那会把创建逻辑和使用逻辑耦合在一起
- 如果活动类型多于 5 种，考虑用策略名字符串作 key 建个映射表，但映射表本身不应参与决策逻辑
上线前必须验证策略的幂等性和边界值
策略类看似简单，但线上最常出问题的是浮点精度、负数输入、零值处理、超大金额溢出。比如 ManJianStrategy 对 $originalPrice = 299.99 是否真的不触发？$originalPrice = 0 时返回什么？
不要依赖“理论上不会出现”，所有策略类必须自带单元测试，覆盖至少三组数据：正常值、临界值、异常值。
- 测试用例必须包含
float类型输入，PHP 中100 * 0.8和bcadd('100', '-20', 2)结果可能不同 - 禁止策略类内部抛出未声明的异常，所有错误应转为返回默认值（如原价）或由上下文统一兜底
- 高并发下，如果策略涉及共享资源（如计数器），必须加锁或改用原子操作，否则会出现超发
实际扩展一个新活动，只需三步：写新策略类 → 单元测试跑通 → 上下文传入实例。没有修改旧代码，也没有新增条件分支。最难的从来不是加功能，而是确保新加的策略不悄悄破坏已有活动的计算逻辑。
