策略类必须实现统一接口（如PaymentStrategy），上下文类通过依赖注入接收策略实例并委托调用，策略间须无状态、不共享数据，参数类型应具体明确，避免隐式依赖与过度设计。
策略类必须实现统一接口，否则无法动态替换
策略模式的核心是“行为可插拔”，不是写几个相似函数就叫策略。PHP里必须定义一个接口（比如 PaymentStrategy），所有具体策略（AlipayStrategy、WechatPayStrategy）都 implements 它。漏掉这步，运行时调用 $strategy->pay() 就会报 Fatal error: Call to undefined method。
- 接口只声明方法签名，不写逻辑；各策略类各自实现，互不影响
- 别用抽象类代替接口——除非真有共用逻辑要抽离，否则增加耦合
- 接口方法参数要一致：比如
process(array $data)，不能一个策略收$order_id，另一个收Order $obj
上下文类（Context）不负责创建策略，只接收和委托
Context 类（比如 PaymentProcessor）的作用是持有策略实例并转发调用，它不该知道怎么 new 出 AlipayStrategy。硬编码 new AlipayStrategy() 在 Context 里，就等于把策略选择逻辑锁死了。
- 策略实例应该由外部传入，通常是构造函数注入：
new PaymentProcessor(new WechatPayStrategy()) - 如果需要运行时切换，提供
setStrategy(StrategyInterface $s)方法即可 - 别在 Context 里做 if-else 判断该用哪个策略——那是工厂或路由层的事
策略之间不能共享状态，避免隐式依赖
常见错误是让多个策略类共用一个 static $cache 或全局配置变量。一旦 A 策略改了缓存，B 策略下次执行就可能读到脏数据，尤其在 CLI 或长生命周期 Swoole 场景下更危险。
- 每个策略实例应完全无状态，或仅依赖自己构造时传入的依赖（如
Logger $logger） - 需要共享数据？交给 Context 或独立的服务类（如
PaymentCache），通过依赖注入传进去 - 测试时容易暴露这个问题：两个策略单元测试一起跑，第二个失败，大概率是状态污染
PHP 8+ 可用联合类型约束策略参数，但别过度设计
比如 public function validate(mixed $input): bool 看起来灵活，实际会让策略行为难以预测。不同策略对 $input 的结构要求不同，硬塞成 mixed 只会让调用方不断 try-catch 或 is_array() 判断。
立即学习“PHP免费学习笔记（深入）”；
- 优先用具体类型：如
array{id: string, amount: float}或 DTO 对象 - 如果真要支持多种输入，定义明确的转换层（如
InputAdapter），不在策略内部处理格式兼容 - PHP 7.4+ 的属性类型、8.0+ 的构造函数属性提升，能帮你提前发现类型错配，别关着不用
