这是一个或许对你有用的社群 一对一交流/面试小册/简历优化/求职解惑欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料《项目实战视频》从书中学往事中“练”《互联网高频面试题》面朝简历学习春暖花开《架构 x 系统设计》摧枯拉朽掌控面试高频场景题《精进 Java 学习指南》系统学习互联网主流技术栈《必读 Java 源码专栏》知其然知其所以然这是一个或许对你有用的开源项目国产Star破10w的开源项目前端包括管理后台、微信小程序后端支持单体、微服务架构RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能多模块https://gitee.com/zhijiantianya/ruoyi-vue-pro微服务https://gitee.com/zhijiantianya/yudao-cloud视频教程https://doc.iocoder.cn【国内首批】支持 JDK17/21SpringBoot3、JDK8/11Spring Boot2双版本来源这道题面试官真正在筛什么30 分答案背得出策略模式 4 个核心优势60 分答案用真实业务场景演示 if-else 怎么烂的90 分答案知道何时不该上策略模式直接掉分的几种答法高频追问怎么接我的判断这道题面试官真正在筛什么「3 个 if-else 也要用策略模式吗」——这道京东面试题表面问「该不该上策略模式」——其实在筛 3 个能力能不能讲清策略模式真正解决什么问题——不是「让代码看起来像 OOP」是开闭原则 单一职责 可测试 可复用——光说代码更整洁是面试官最讨厌的空话会不会用真实业务场景讲清if-else 怎么变烂的——光画几个抽象Type1 / Type2 / Type3是背书用促销 / 支付 / 风控这种真实场景演示才是踩过坑的有没有「不该上策略模式」的工程判断力——这是最关键的加分项——面试官最怕招到无脑套设计模式的人——3 个 if-else 也要上、把项目搞成 100 个微小的策略类——这种人接手老项目就是灾难。按这三档下面给30 / 60 / 90 分答案。基于 Spring Boot MyBatis Plus Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/ruoyi-vue-pro视频教程https://doc.iocoder.cn/video/30 分答案背得出策略模式 4 个核心优势如果只能用 30 秒回答先列策略模式 vs if-else 的 4 个核心差异优势if-else策略模式新增分支改原方法、违反开闭原则新加一个策略类、不动原代码单一职责所有逻辑挤在一个方法里每个策略一个独立类可测试性要构造各种条件测一个方法每个策略类独立写单测可复用性逻辑绑死在方法里策略类可在任何地方注入一句话兜底策略模式不是为了模式而模式——是用「类的扩展」替代「方法的修改」——本质是开闭原则的体现。但仅答到这 30 分线——背得出概念但没踩过坑、面试官还会追问。基于 Spring Cloud Alibaba Gateway Nacos RocketMQ Vue Element 实现的后台管理系统 用户小程序支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能项目地址https://github.com/YunaiV/yudao-cloud视频教程https://doc.iocoder.cn/video/60 分答案用真实业务场景演示 if-else 怎么烂的到 60 分线必须用一个真实业务场景讲清if-else 是怎么从 50 行烂成 500 行的。场景电商促销系统运营每周加新活动类型最初版本只有 3 种促销一个if-else看起来很合理public BigDecimal calculatePrice(String promotionType, BigDecimal price) { if (normal.equals(promotionType)) { return price; // 无优惠 } else if (discount.equals(promotionType)) { return price.multiply(new BigDecimal(0.8)); // 打八折 } else if (fullReduction.equals(promotionType)) { return price.compareTo(new BigDecimal(100)) 0 ? price.subtract(new BigDecimal(20)) : price; // 满 100 减 20 } throw new IllegalArgumentException(未知促销类型); }3 个分支没什么问题——这就是 90 分答案那一节会讲的「不该上策略模式」的场景。但运营开始隔三差五加活动——半年后这个方法变成这样public BigDecimal calculatePrice(String promotionType, BigDecimal price) { if (normal.equals(promotionType)) { ... } elseif (discount.equals(promotionType)) { ... } elseif (fullReduction.equals(promotionType)) { ... } elseif (buyOneGetOne.equals(promotionType)) { ... } elseif (newUser.equals(promotionType)) { ... } elseif (vip.equals(promotionType)) { ... } elseif (groupBuy.equals(promotionType)) { ... } // ... 还有 13 个分支 }真实项目里促销类型 20 种、每个分支不止一行要查用户等级、查活动库存、计算叠加优惠一个方法 500 行不是梦。4 个翻车点全来了❌ 加「拼团优惠」要在 500 行方法里找位置插一个else if——祈祷不影响其他逻辑❌ 改fullReduction的 bug、手一抖把buyOneGetOne也改了❌ 想单独测「满减」的计算——要构造一堆参数跑整个方法❌ 另一个服务也想用「打折」——只能复制粘贴。用 Spring 注入解构成策略模式// 策略接口 publicinterface PromotionStrategy { BigDecimal calculate(BigDecimal price); } // 每个促销一个独立类 Component(discount) publicclass DiscountStrategy implements PromotionStrategy { Override public BigDecimal calculate(BigDecimal price) { return price.multiply(new BigDecimal(0.8)); } } Component(fullReduction) publicclass FullReductionStrategy implements PromotionStrategy { Override public BigDecimal calculate(BigDecimal price) { return price.compareTo(new BigDecimal(100)) 0 ? price.subtract(new BigDecimal(20)) : price; } }业务代码Service publicclass PromotionService { Autowired private MapString, PromotionStrategy strategyMap; // Spring 自动把所有 PromotionStrategy 实现注入这个 Map // key Bean 名称value 策略实例 public BigDecimal calculatePrice(String promotionType, BigDecimal price) { PromotionStrategy strategy strategyMap.get(promotionType); if (strategy null) { thrownew IllegalArgumentException(未知促销类型 promotionType); } return strategy.calculate(price); } }4 个翻车点全消失痛点if-else 处理方式策略模式处理方式新增「拼团」在 500 行方法里加else if新加一个GroupBuyStrategy.java、Component(groupBuy)——一行原代码不动改满减 bug可能误伤打折只改FullReductionStrategy、其他文件不受影响测试满减跑整个方法new FullReductionStrategy().calculate(...)直接测复用打折复制粘贴注入DiscountStrategy即可讲到这就到 60 分线——能用真实场景演示 解出 4 个痛点的对应解。90 分答案知道何时不该上策略模式90 分线的关键——策略模式有缺点——光夸不批评 没思考过。缺点 1类爆炸每加一种策略多一个类。20 种促销 20 个文件——文件树会变长、新人找代码要多一步。修法① 给策略类加业务前缀PromotionDiscountStrategy而不是DiscountStrategy②同业务的策略放同一个包里不要散落在 service 各处。缺点 2客户端要知道有哪些策略问题调用方要传discount这种字符串——typo 一个字母运行时才报错。修法用枚举做策略 key替代字符串public enum PromotionType { NORMAL(normal), DISCOUNT(discount), FULL_REDUCTION(fullReduction); // ... } // 调用 strategyMap.get(PromotionType.DISCOUNT.getCode()); // 编译期检查typo 不了缺点 3跨策略的通用逻辑要抽10 种促销都要先校验用户等级、再校验活动库存——这部分通用逻辑塞到哪修法抽法实现抽象类推荐AbstractPromotionStrategy——通用逻辑写在父类、各策略只重写calculatePrice()责任链用一条链把「校验 → 计算」串起来——校验失败直接退出何时不该上策略模式判断标准一张表维度用 if-else上策略模式分支数量≤ 3 个≥ 5 个未来扩展性几年都不会变经常加新分支每个分支的代码量 5 行 20 行是否需要独立测试不需要需要是否被多处复用仅一处多处我的判断标准一句话「分支少且稳定用 if-else分支多且常变上策略」——这就是3 个 if-else 不该上策略模式的核心理由。面试中的反问技巧面试官问「3 个 if-else 该不该用策略模式」——正面答完后反问一句「这 3 个分支未来会不会扩展每个分支的代码量大概多少需不需要独立测试」——这一反问就比直接答更有专业感——面试官会给你打高分。直接掉分的几种答法❌ 策略模式更好应该用→ -50 分。任何「绝对优先」的答案都暴露没思考过——面试官就在等这种反应。❌ 3 个分支也要上策略模式讲了 4 个优势→ 直接被刷。3 个简单分支的if-else是最自然的写法——上策略模式 过度设计的活样本。❌ if-else 是反模式→ 大学课本水平。if-else 不是反模式——滥用的 if-else 才是反模式——这一字之差是工程素养的分水岭。❌ 只讲优点不讲缺点→ 顶多 60 分。会不会讲缺点是 90 分线的核心区分。❌ 策略模式肯定能消灭所有 if-else→ -30 分。**if (strategyMap.get(type) null)这种 null 检查的if** 改不掉——消灭的是「业务分支」不是所有 if。高频追问怎么接追问 1策略模式有什么替代方案4 种——按推荐度排替代方案适用场景MapString, Function简单计算逻辑——用 lambda 替代策略类——轻量级首选枚举enum分支固定、不会扩展——每个枚举实例实现接口方法——最简洁工厂模式 多态策略需要复杂初始化注入 dao / 配置责任链模式多个策略按顺序匹配——找到第一个 match 的就用追问 2项目里在哪用到了这题要结合自己项目讲——常见落地点支付方式选择微信 / 支付宝 / 银联 / 余额——每种一个PaymentStrategy促销折扣计算满减 / 折扣 / 拼团 / VIP——上面演示的那个消息推送渠道站内信 / 短信 / 邮件 / Push——每种一个NotifyStrategy数据导出格式Excel / CSV / PDF / JSON——每种一个ExportStrategy风控策略黑名单 / 速率限制 / 设备指纹 / 行为分析——每种一个RiskStrategy。追问 3策略模式 vs 状态模式有啥区别结构上几乎一样——但意图不同策略模式让客户端选策略——「我要打八折」 / 「我要满减」——主动决定状态模式对象内部状态变化导致行为变化——订单从「待支付」 → 「已支付」 → 「已发货」——对象自动迁移。记忆口诀策略是给的、状态是变的。追问 4策略类一直在新增、文件树越来越长怎么办3 个办法按业务模块分包promotion/strategy/、payment/strategy/而不是strategy/大杂烩配置化策略把简单计算逻辑如折扣率抽到配置文件 / 数据库用一个通用ConfigDrivenStrategy替代多个简单类分层抽象基类抽公共逻辑、子类只写差异——减少类的总数。我的判断这道题答到 30 分容易、答到 60 分要会用真实业务讲、答到 90 分靠工程判断力。面试时 3 步走法先讲 4 个优势→ 过基础线用真实场景促销 / 支付演示 if-else 怎么变烂的、策略模式怎么解→ 60 分最后甩工程判断「分支少且稳定用if-else分支多且常变才上策略模式」——3 个 if-else 我自己也写 if-else→ 直接 90 分线。说到底设计模式是工具——不是炫技的资本。你能说出什么时候不该用 X——比 100 个能背出 X 用法的候选人都值钱。面试官这道题筛的就是这种判断力——背模式背不到、踩坑才能踩到。最后一句如果哪天你看老代码看到 100 个微小的策略类——大概率是过去某位想表演设计模式的同事留下的债。好工程师不是用最多模式的人——是知道什么时候不用模式的人。欢迎加入我的知识星球全面提升技术能力。 加入方式“长按”或“扫描”下方二维码噢星球的内容包括项目实战、面试招聘、源码解析、学习路线。文章有帮助的话在看转发吧。 谢谢支持哟 (*^__^*