应优先用策略模式替代条件分支，将订单状态处理等逻辑下沉为类方法；其次可用原型动态覆写实现实例级行为定制；对叠加型逻辑则采用object.assign或proxy组合增强；但仅2–3个简单分支时保留if-else更清晰。
用原型继承配合方法动态覆写，能把大量硬编码的 if-else 拆解成可插拔、易测试、易扩展的对象行为，核心在于“把分支逻辑下沉为类/实例的方法”，而非在调用处堆条件判断。
用策略对象替代条件分支
将每个业务分支封装为独立策略类，共享统一接口，运行时根据上下文选择对应实例。例如订单状态处理：
- 定义基类 OrderHandler，含 handle() 抽象方法
- 子类 PaidHandler、RefundedHandler、CancelledHandler 分别实现各自逻辑
- 用工厂函数根据 order.status 返回对应 handler 实例，调用 .handle() 即可，零 if-else
利用原型链动态挂载/替换方法
不需预定义所有子类，可在运行时按需增强或覆盖行为。比如针对不同客户等级定制通知方式：
- 基础 Notifier 原型有 send() 方法，默认发站内信
- 对 VIP 用户，直接修改其实例的 send 属性：user.notifier.send = function() { /* 发短信 */ }
- 对黑名单用户，甚至可临时屏蔽：user.notifier.send = function() {}
- 这种覆写只影响当前实例，不影响其他对象，灵活且无副作用
结合 Object.assign 或 Proxy 实现轻量行为组合
当逻辑不是严格“互斥分支”而是“叠加增强”时，避免深层继承，改用组合：
- 定义多个能力模块：{ withEmail: ..., withSMS: ..., withRetry: ... }
- 根据配置用 Object.assign(notifier, withEmail, withRetry) 拼装行为
- 更进一步可用 Proxy 拦截方法调用，在执行前自动注入通用逻辑（如日志、熔断），彻底解耦横切关注点
注意边界：何时不该强行消灭 if-else
并非所有分支都适合策略化。以下情况保留简单 if-else 更清晰：
- 只有 2–3 个分支，且逻辑极简（如 if (type === 'A') return 1; else return 2;）
- 分支依据是临时计算值、非稳定状态（如 if (Date.now() > deadline)）
- 团队对 OOP 理解较浅，过度设计反而增加理解成本
关键不在消灭 if-else，而在让代码结构反映业务本质——状态驱动行为，就用策略；行为需动态装配，就用原型覆写或组合；保持意图透明，比语法“优雅”更重要。
