我之前接手过一个电商项目的促销模块那段代码现在想起来还觉得头大。当时的需求是根据用户等级算折扣。普通用户不打折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){// 换个角度想这里其实就是个“插件调用器”conststrategypriceStrategies[level]||priceStrategies[DEFAULT];returnstrategy(price);};// 2. 使用console.log(VIP 价格:,calculatePrice(VIP,100));// 90console.log(新人价格:,calculatePrice(NEW_USER,100));// 50换个角度想这种写法最舒服的地方在于…这种写法最爽的地方在于它实现了完美的“即插即用”。你想想如果你明天想加个“双十一大促”你只需要在priceStrategies对象里加一行代码。你完全不需要去动calculatePrice这个核心函数。这就把原本沉重的“修改代码”变成了轻松的“增加配置”。还有一个细节这种模式让单元测试变得极其简单。你可以单独测试priceStrategies.VIP这个函数算得准不准。你不需要去模拟一整个复杂的促销环境只需要测那一个“算法切片”就行。两种写法的直观对比容易出问题的写法硬编码判断if(typeVIP){...} else if(typeSVIP){...}后果逻辑死死焊在一起。规则越多函数越长。想改其中一个逻辑请在几百行代码里大海捞针。更稳健的策略模式写法strategies[type](data)后果每个算法都是独立的“小插件”。代码结构清晰得像说明书一眼就能看出系统支持哪些规则每个规则是怎么算的。给你的 2 条行动建议看到“分支判断”就警惕只要你的代码里出现了超过 3 个if-else或者switch且每个分支都在做不同的计算别犹豫直接把它们抽成策略对象。配合“工厂模式”使用如果你的策略对象创建过程比较复杂可以先用工厂模式把策略造出来再传给执行函数。这样你的代码会更有层次感。我以前总觉得写个if-else多快啊搞这么多对象不是多此一举吗后来才明白真正的专业是学会把“变动的逻辑”关进“固定”的盒子里。策略模式就是给你的代码装上了一套“插件系统”。