21 | 别再写那堆恶心的 if-else 了：给你的代码装个“插件盒”——策略模式
我之前接手过一个电商项目的促销模块，那段代码现在想起来还觉得头大。
当时的需求是：根据用户等级算折扣。
普通用户不打折，VIP 打 9 折，超级 VIP 打 8 折。
我当时写得特别顺手，直接一个if-else搞定。
结果后来业务又加了“节日促销”、“新人专享”、“满减活动”……
那个算价函数直接膨胀到了两百行，里面全是嵌套的判断。只要改一个规则，另外五个规则都得跟着测一遍，生怕算错一分钱。
我当时就跟同事复盘：我们不应该把所有的“算价逻辑”都塞进一个脑袋里。
它不应该是一个“多面手”，而应该是一个“工具箱”。
你需要哪种算法，直接从箱子里掏出来用就行。
这种定义一系列算法，把它们一个个封装起来，并且使它们可以相互替换的套路，就是策略模式（Strategy Pattern）。
为什么你的判断逻辑总是“越写越乱”？
先聊聊这个现象：我们太习惯于用“分支语句”来解决问题了。
你觉得if (type === 'A')只是一个简单的判断。
但换个角度想，每一个if后面其实都藏着一套完全不同的“业务策略”。
说白了，这种麻烦是因为你试图在一个地方，去管好几件完全不相干的事。
你在算 VIP 折扣的时候，还得操心“满减活动”的代码。
这就像是你开了一家餐厅，厨师不仅要炒菜，还得负责洗碗、收银、修电梯。
只要电梯坏了，厨师就没法炒菜，整个餐厅就瘫痪了。
点破真相：真正的解耦，是把“怎么算”和“什么时候算”彻底分开。
你只需要定义好一堆“算法插件”，用的时候直接按需调用，主流程根本不需要关心细节。
在 JS 里，策略模式就是“对象映射表”
在 Java 里，你可能要写一堆Strategy接口和具体的实现类。
但在 JavaScript 里，我们有更灵动的玩法：利用对象字面量（Object Map）来存储函数。
咱们来看看，怎么把那个乱成一团的“促销逻辑”理顺。
// 0. 关键：定义策略盒（每个算法只管自己的活）// 这种写法最爽的地方在于：你想加新规则，只需要往盒子里塞个新函数constpriceStrategies={'VIP':(price)=>price*0.9,'SVIP':(price)=>price*0.8,'NEW_USER':(price)=>price*0.5,'DEFAULT':(price)=>price};// 1. 核心本体：算价函数// 它现在变得极其纯粹，只负责“查表”和“执行”constcalculatePrice=(level,price)=>{// 换个角度想，这里其实就是个“插件调用器”conststrategy=priceStrategies[level]||priceStrategies['DEFAULT'];returnstrategy(price);};// 2. 使用console.log('VIP 价格:',calculatePrice('VIP',100));// 90console.log('新人价格:',calculatePrice('NEW_USER',100));// 50换个角度想，这种写法最舒服的地方在于…
这种写法最爽的地方在于：它实现了完美的“即插即用”。
你想想，如果你明天想加个“双十一大促”，你只需要在priceStrategies对象里加一行代码。
你完全不需要去动calculatePrice这个核心函数。
这就把原本沉重的“修改代码”变成了轻松的“增加配置”。
还有一个细节：这种模式让单元测试变得极其简单。
你可以单独测试priceStrategies.VIP这个函数算得准不准。
你不需要去模拟一整个复杂的促销环境，只需要测那一个“算法切片”就行。
两种写法的直观对比
容易出问题的写法（硬编码判断）：if(type==='VIP'){...} else if(type==='SVIP'){...}
后果：逻辑死死焊在一起。规则越多，函数越长。想改其中一个逻辑？请在几百行代码里大海捞针。
更稳健的策略模式写法：strategies[type](data)
后果：
每个算法都是独立的“小插件”。
代码结构清晰得像说明书，一眼就能看出系统支持哪些规则，每个规则是怎么算的。
给你的 2 条行动建议
看到“分支判断”就警惕：只要你的代码里出现了超过 3 个
if-else或者switch，且每个分支都在做不同的计算，别犹豫，直接把它们抽成策略对象。配合“工厂模式”使用：如果你的策略对象创建过程比较复杂，可以先用工厂模式把策略造出来，再传给执行函数。这样你的代码会更有层次感。
我以前总觉得，写个if-else多快啊，搞这么多对象不是多此一举吗？
后来才明白，真正的专业，是学会把“变动的逻辑”关进“固定”的盒子里。
策略模式，就是给你的代码装上了一套“插件系统”。