如何处理PHP中不断增加的业务活动需求？应用策略模式快速扩展活动类型

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