什么情况下不建议在JS中使用策略模式？

一、重新审视：策略模式在 JavaScript 中的现实成本

在传统面向对象语言（如 Java、C++）中，策略模式具有极高的实用价值：因为函数不能独立存在，要实现运行时多态，必须显式定义策略接口、编写具体的策略实现类，再通过上下文（Context）类进行注入与委托。

然而在 JavaScript 中，函数本身就是一等公民（First-Class Citizen），对象字面量更具备极其高效的动态键值寻址能力。很多开发者在学习重构时形成了一种思维惯性，将“消灭一切 if-else 或 switch”视为代码重构的终极指标，看到分支语句就试图改写为策略模式。

这种生搬硬套往往忽视了设计模式本身所需支付的“抽象税”：

• 上下文跳转成本：原本连续内联的代码被切碎分布在多个策略函数甚至独立模块中，排查问题时必须在调用处、分发字典和策略实现之间来回跳跃。
• 参数规范成本：所有策略函数必须遵循极其一致的入参与返回值签名，哪怕某些分支只需一个参数，也必须接受完整的冗余上下文对象。
• 认知与维护负担：新接手项目的开发者为了理解一个本该由几行简单判断完成的业务，必须先理解调度器生命周期与策略注册机制。

因此，判断是否该使用策略模式，本质上是在“算法扩展的自由度”与“增加间接层的理解成本”之间进行权衡。

二、技术选型：是否采用策略模式的 4 步决策流程

为了避免凭主观偏好做架构决定，可以通过以下 4 个具体的判断步骤，逐层检验手头的业务逻辑是否真的需要策略模式：

步骤 1：评估分支规模与变动频率

统计当前分支的总数量，并结合业务蓝图确认未来 6 个月内是否会有新分支增加。如果分支总数不超过 3 个，且属于固定的二元逻辑（例如开启/关闭、深色/浅色、登入/登出），直接使用 if-else 或三元表达式即可。

步骤 2：识别分支内的逻辑本质是“算法”还是“数据”

检查分支内部究竟在做什么。如果分支只是根据一个状态标识返回一段中文文本、颜色值、图标名称或跳转路由，这本质上是静态数据映射而非可互换的行为算法。此时应当采用轻量查表法（对象字面量或 Map），不建议封装执行函数。

步骤 3：检测分支间是否存在状态依赖与副作用

分析各分支的执行逻辑是否独立。如果分支 A 的执行结果需要被分支 B 读取，或者各分支需要直接修改外部宿主上下文的私有属性，这属于典型的有状态时序逻辑。策略模式要求各个策略完全解耦互换，强行套用策略模式会导致上下文状态污染，应改用有限状态机（FSM）或管道模型（Pipeline）。

步骤 4：确认算法体量与插件化需求

只有当单分支算法逻辑较为复杂（通常超过 30 行独立计算），且业务明确要求支持运行时动态挂载、注销或由不同业务包独立提供算法时，才推荐采用基于 JavaScript 对象和函数的轻量策略模式。

三、四种不建议在 JS 中使用策略模式的典型场景

1. 分支极少（2~3个）且业务规则长期固定

最常见的一种过度设计，就是在简单的二元判断中强推策略模式。例如根据用户是否开通 VIP 计算折扣：

// ❌ 过度设计的写法：为了消除 if-else 强行引入策略对象
const discountStrategies = {
  VIP: (price) => price * 0.8,
  REGULAR: (price) => price
};

function getPrice(userType, price) {
  const strategy = discountStrategies[userType] || discountStrategies.REGULAR;
  return strategy(price);
}

上述代码增加了 discountStrategies 对象的内存分配与间接查找过程。而现实中用户类型可能多年内只有普通与 VIP 两种状态。推荐写法极其简单：

// ✅ 推荐实践：简洁明了的内联分支或三元运算符
function getPrice(isVip, price) {
  return isVip ? price * 0.8 : price;
}

2. 分支仅用于静态值或纯属性映射（将数据误当算法）

在管理后台与展示类业务中，经常需要根据数字状态码展示标签文案与配色。许多开发者习惯将其写成策略对象，甚至在每个策略中返回一个方法：

// ❌ 不推荐：把静态数据查表硬写成带执行函数的策略模式
const statusStrategies = {
  100: {
    render: () => ({ text: "待支付", color: "orange" })
  },
  200: {
    render: () => ({ text: "已支付", color: "green" })
  },
  300: {
    render: () => ({ text: "已退款", color: "red" })
  }
};

const currentStatus = statusStrategies[code]?.render();

这里的 render() 函数没有任何动态运算，只是凭空包装了一层闭包与调用开销。真正需要的只是只读数据字典：

// ✅ 推荐实践：声明式静态常量配置对象（数据查表法）
const STATUS_META_MAP = Object.freeze({
  100: { text: "待支付", color: "orange" },
  200: { text: "已支付", color: "green" },
  300: { text: "已退款", color: "red" }
});

// 提取数据与兜底保障
const currentStatus = STATUS_META_MAP[code] ?? { text: "未知状态", color: "gray" };

3. 分支之间存在高度耦合的上下文状态与时序副作用

策略模式成立的黄金法则，是策略之间完全互不干扰，算法彼此独立。如果在业务执行过程中，策略 A 执行完后修改了共享上下文，策略 B 必须读取这个改动才能继续运行，那么使用策略模式就是一个严重的架构失误。

例如，在一个多步骤表单提交的校验场景中：

// ❌ 错误示范：策略在共享上下文中产生隐式副作用
const stepStrategies = {
  step1: (context) => {
    // 策略直接污染 context 对象
    context.userToken = generateToken(context.userId);
    context.step1Completed = true;
  },
  step2: (context) => {
    // 强依赖上一步由策略 1 注入的隐蔽属性
    if (!context.step1Completed) throw new Error("前置步骤未完成");
    verifyToken(context.userToken);
  }
};

在上述代码中，各个策略实际上形成了一条隐蔽的时序依赖链条。如果外部调用顺序被颠倒，或者某些参数被策略悄悄修改，开发者极难定位是哪一个策略产生了副作用。

替代方案：

• 如果逻辑是有序流转的校验管道，请使用纯函数管道（Pipeline）：每个函数接受入参并返回新数据，不修改外部对象。
• 如果涉及复杂状态切换（如从待审核流转到处理中、驳回），请使用有限状态机（Finite State Machine）：明确定义 state 与 events 的转移矩阵。

4. 强行套用传统面向对象的类与调度器结构

在经典设计模式书籍中，策略模式通常包含 Context 类、Strategy 抽象类以及 ConcreteStrategyA / B 实现类。很多开发者在 JavaScript 或 TypeScript 项目中原封不动地照搬这一套结构：

// ❌ 在 JS 中生搬硬套面向对象的重度实现
class PaymentContext {
  constructor(strategy) {
    this.strategy = strategy;
  }
  setStrategy(strategy) {
    this.strategy = strategy;
  }
  executePayment(amount) {
    return this.strategy.pay(amount);
  }
}

class AliPayStrategy {
  pay(amount) { /* 支付逻辑 */ }
}

class WeChatPayStrategy {
  pay(amount) { /* 支付逻辑 */ }
}

// 业务调用需多层实例化
const context = new PaymentContext(new AliPayStrategy());
context.executePayment(100);

在 JavaScript 中，这种结构带来了近 5 倍的冗余代码。JS 天然支持对象高阶函数分发，完全可以通过更简洁的声明式对象来承载：

// ✅ 符合 JavaScript 语言特性的轻量策略写法
const payActions = {
  alipay: (amount) => requestAliPay(amount),
  wechat: (amount) => requestWxPay(amount),
  apple: (amount) => requestApplePay(amount)
};

function handlePayment(channel, amount) {
  const action = payActions[channel];
  if (!action) {
    throw new Error(`暂不支持的支付通道: ${channel}`);
  }
  return action(amount);
}

不需要实例化 Context，不需要继承抽象类，几行代码即可完成分发与安全调用。

四、全景速查：不同场景的替代方案与定位矩阵

为了帮助团队在代码评审与重构时快速达成共识，下表总结了分支场景与具体设计方案的对应关系：

五、总结：在代码简洁与预留扩展之间保持克制

在编写 JavaScript 代码时，架构设计的核心目标是降低整体系统的维护复杂度，而不是证明自己熟练掌握了多少种设计模式。

在决定将一段分支逻辑重构为策略模式之前，建议向自己提出以下三个问题：

1. “未来真的会频繁添加第 4、第 5 个分支吗？” 如果概率极低，请严格遵循 YAGNI（You Aren't Gonna Need It）原则，保持现状。
2. “分支内部是在执行算法，还是仅仅在查数据？” 如果只是静态关联，请立即改用普通对象字典或 Map 查表。
3. “团队新人阅读这段代码时，一眼就能看清主干流程吗？” 如果改写为策略模式后，排查一个 Bug 需要在多个文件中来回定位，说明抽象已经过头。

从最简单的 if-else 开始，到提取为私有辅助函数，再到数据字典查表，最后在真正需要多态时按需演进为轻量策略对象——这种渐进式的重构节奏，才是保证 JavaScript 工程健康、敏捷的最佳途径。