开闭原则落地指南：策略模式、抽象与支付模块重构，如何对扩展开放对修改关闭

"开闭原则"这四个字，我职业生涯里听了不下几百遍，但真正让我脊背发凉的，是某次凌晨两点在生产环境回滚代码的那一刻。那一次，只是为了给订单模块加一种新的促销类型，我改了老代码里的一个if判断，结果把正常下单的流程也带崩了。从那以后我才彻底想明白，所谓"开闭原则（OCP）"，不是说给架构师写PPT用的漂亮口号，它在绝大多数场景下，就是决定你能不能准点下班、系统能不能安稳上线的生死线。

开闭原则的核心只有一句话：对扩展开放，对修改关闭。翻译成大白话就是，当产品经理提新需求、要加新功能时，你理想的操作是"新增"——新增一个类、新增一个配置、新增一个模块，而不是"修改"——修改已经上线、已经稳定运行的核心类和方法。这篇文章我不会跟你念教科书，我直接把OCP拆开揉碎，结合我这几年在真实项目里的重构案例、踩坑现场和排查过程，讲清楚它到底怎么落地，以及什么时候该适可而止。不管你是刚入行的初级开发，还是已经开始带项目的中坚力量，这篇内容都能给你一个可以直接抄作业的思路。

1. 开闭原则(OCP)的真面目：它到底是设计原则还是业务策略

1.1 从"开"和"闭"的字面意思说起

很多人第一次接触开闭原则，容易被"开"和"闭"这两个字绕晕。开是open，闭是closed，但这里的开闭不是互相矛盾的，而是落在两个不同的对象上：对扩展开放，说的是系统在功能层面要留好余地，让新功能有地方放；对修改关闭，说的是系统在既有代码层面要尽量稳定，已经跑得好好的东西别去动它。

我用一个生活化的例子解释。你家请了一位钟点工阿姨，她负责做饭。今天你想吃西红柿炒蛋，直接告诉她就行；明天你想吃红烧肉，也直接告诉她就行。这是对扩展开放。但如果阿姨来了半年，你突然说"从今天开始，你每次做饭前都得先洗一遍油烟机"，阿姨的原有工作流程就被你改了，她可能会把饭做糊，因为她的精力被分散了。这就是改动老代码带来的风险。

在软件系统里也一样。一个线上跑了半年的支付服务，它的下单、对账、退款逻辑已经经过了各种测试和线上流量的考验。这时候你说加一个支付宝的支付渠道，结果你去改了核心的下单流程代码，加了一个if判断。看起来只是三行代码的事，但这个改动会让整条核心链路重新处于风险之中，因为你无法确认这三行代码会不会影响到其他还在用老逻辑的渠道。

1.2 违反OCP的经典模样：if/else与switch的滥用

我对违反OCP的代码有一种生理性的警觉，只要看到大段大段的if/else或者switch堆积在核心方法里，我就知道这个地方迟早要出事。举个例子，一套订单配送系统，运费计算就一个方法，里面用switch判断物流公司：

java复制public double calculateShippingFee(Order order) {
    switch (order.getShippingCompany()) {
        case "SF":
            // 顺丰运费逻辑
            return order.getWeight() * 15;
        case "ZT":
            // 中通运费逻辑
            return order.getWeight() * 8 + 5;
        case "YT":
            // 圆通运费逻辑
            return order.getWeight() * 7 + 3;
        default:
            throw new IllegalArgumentException("不支持的物流公司: " + order.getShippingCompany());
    }
}

这段代码在只有两三家物流公司的时候很爽，逻辑清晰，一次写完，改起来也直接。但物流公司的数量不会停在两三家，很快第四家来了、第五家来了，每加一家，你都要打开这个已经上线的方法，在switch里加一个case，然后重新测试所有物流公司的运费逻辑，因为你根本无法确定你这次的改动是否破坏了顺丰和圆通的分支。

这种代码的问题不在于switch本身，而在于整个运费计算的核心方法被迫成为所有变化点的汇聚中心。每增加一种方式，核心方法就膨胀一点，直到它变得无比臃肿，没人敢再动它。这就是OCP被违反之后最典型的症状：核心模块的代码行数随着业务扩展而不断增长，且每一次增长都带来回归测试的代价。

1.3 为什么"不改老代码"不是一个洁癖，而是风险控制

有人可能会想，改老代码就改呗，我小心一点不就行了。这里我想说一个很多人忽略的事实：代码是有"记忆"的，这个记忆不在代码本身，而在所有依赖它的外部系统、调用方和隐式约定里。

举个例子，有个类叫PaymentService，它有一个方法叫pay(Order order)。这个方法的内部逻辑一直被另一个团队开发的财务核算系统间接使用，他们通过消息队列接收订单支付事件。如果你在pay方法里为了新增一种支付方式，把订单金额的精度处理逻辑提前了，虽然你的单元测试可能全绿，但财务系统的对账脚本可能就收到了精度被提前处理的数据，导致他们那边的汇总对不上。

改动老代码的真正风险，是你根本不知道到底有多少隐藏的调用方在依赖它的现有行为。哪怕你现在是单体应用，代码里所有调用点都能搜到，那部署之后呢？消息发出去，下游怎么消费，你控制不了。所以我认为OCP在本质上不是一种代码洁癖，而是一种风险控制策略——核心代码的每一次改动，都是在用整个系统的稳定性下注。

2. 落地的核心手段：抽象、多态与组合

2.1 抽象是OCP的地基，但别把抽象做成空中楼阁

要让代码对扩展开放、对修改关闭，第一步是要识别出系统中"会变化的部分"和"稳定的部分"。稳定的是骨架，变化的是血肉。骨架通过抽象来定义，血肉通过具体实现来填充。

在Java里最常用的手段就是接口和抽象类。接口定义契约，约定这个能力"要做什么"，但不关心"怎么做"。新功能接入时，实现一个新的类，实现接口里的方法，然后在某个注册中心把新实现挂上去，老代码一行都不用动。

但我要泼一盆冷水：抽象不是越多越好，不是所有地方都需要接口。很多团队喜欢给每个service都配一个interface，美其名曰面向接口编程，结果接口里的方法长期只有一个实现，这纯粹是在给系统增加无意义的复杂度。真正的抽象必须建立在多变的业务场景之上。你在什么地方预见到会有多种实现、多种策略、多种渠道，你才在什么地方引入抽象。

一个比较好的判断技巧是：当你第二次需要在同一个地方写if/else去区分不同的业务类型时，就是一个信号，这里的抽象时机到了。 第一次可能是正常，第二次就是重复，第三次就是灾难。

2.2 策略模式是OCP的黄金搭档

谈到OCP的具体落地，策略模式是我个人用得最多、也见效最快的方式。策略模式的核心思想特别简单：定义一族算法或业务规则，把它们各自封装起来，让它们可以互相替换。这个替换过程不影响使用方。

拿前面的运费计算来说，遵循OCP的改造方式，不是把switch删了，而是把每个物流公司的运费算法都抽取成独立的策略类，核心的运费计算器只管持有当前应该使用哪个策略：

java复制public interface ShippingFeeStrategy {
    String getCompanyCode();
    double calculate(Order order);
}

public class SFShippingFeeStrategy implements ShippingFeeStrategy {
    @Override
    public String getCompanyCode() {
        return "SF";
    }

    @Override
    public double calculate(Order order) {
        return order.getWeight() * 15;
    }
}

public class ShippingFeeCalculator {
    private final Map<String, ShippingFeeStrategy> strategyMap;

    public ShippingFeeCalculator(List<ShippingFeeStrategy> strategies) {
        strategyMap = strategies.stream()
                .collect(Collectors.toMap(ShippingFeeStrategy::getCompanyCode, s -> s));
    }

    public double calculate(Order order) {
        ShippingFeeStrategy strategy = strategyMap.get(order.getShippingCompany());
        if (strategy == null) {
            throw new IllegalArgumentException("暂不支持该物流公司: " + order.getShippingCompany());
        }
        return strategy.calculate(order);
    }
}

改造之后，加了第四家物流公司时，你只需要新建一个类实现ShippingFeeStrategy，然后在Spring容器里把它注册成bean，ShippingFeeCalculator在初始化的时候会自动把它收进map里。老代码一行没动，新功能加好了，这就是策略模式+OCP的威力。

2.3 组合优于继承：扩展点别往父类里塞

在OCP落地过程中，很多初级同学会走向另一个极端：用继承去扩展。他们觉得子类继承父类，重写父类方法，这很符合开闭原则。理论上是，但实践里坑很多。

继承是一种强耦合关系，子类与父类在编译期就绑定了。父类的一个方法签名发生变化，所有子类全得跟着改。而且继承树一深，逻辑分散在各个层级，开发人员看代码时需要在脑子里把整条继承链串联起来，认知负担非常重。

我更推荐组合的方式。组合的意思是，在类里持有另一组能力的引用，需要什么能力就调用什么。还拿运费计算举例子，ShippingFeeCalculator本身就是一种组合，它内部持有一个策略集合，而不是把各种运费逻辑都写在继承链上。

我个人在实际项目里几乎只在两种场景用继承：一种是对抽象类的模板方法模式扩展，即基类定义了算法骨架，子类填充可变细节；一种是真正意义上的"is-a"关系，比如企鹅是鸟类。剩下的大多数场景，组合加接口就够用了。组合方式的另一个好处是测试容易，你可以很轻松地在测试里替换掉某个依赖组件，注入一个mock实现。

2.4 依赖注入：让扩展点在运行时才"现身"

如果把策略模式比作OCP的骨架，那么依赖注入就是把它撑起来的肌肉。在Spring项目里，我们习惯把策略实现类都注册成bean，然后在运行时根据上下文把它们组装起来。这就是依赖注入带来的价值——对象之间的装配关系从代码里剥离出来，放到容器层面管理。

这带来一个巨大的好处：新增一个策略实现类时，容器启动时会自动发现它并注入进去，业务方代码完全不用修改。这不仅仅是"少改几行代码"的问题，而是整个系统的扩展方式从"修改源码、重新发布"变成了"新增代码、无缝接入"。

不过依赖注入也有一个反模式叫"服务定位器"。有些文章试图用ServiceLocator来动态查找实现，拿到一个业务类型字符串，然后反射去加载对应的类。我强烈不建议这么干。反射调用会让代码的调用链变得透明性极差，IDE里点右键"Find Usages"都定位不到谁在用这个类，排查问题时只能靠日志一步步追。Spring的Map注入、List注入已经足够优雅，没必要引入黑魔法。

3. 实战复盘：一个支付模块从"改老代码"到"加新代码"的重构

3.1 第一版：上线快，但埋下了隐患

我有一次接手一个电商项目，最初的需求是接入微信支付。当时团队为了赶上线，直接在OrderService里写了调起支付的方法：

java复制public PayResult pay(Order order) {
    if ("WECHAT".equals(order.getPayChannel())) {
        // 微信支付相关逻辑
        String prepayId = wechatPayClient.createPrepay(order.getOrderNo(), order.getAmount());
        return PayResult.success(prepayId);
    }
    throw new UnsupportedOperationException("未知支付渠道");
}

上线初期当然没问题。但业务方很快说我们要接入支付宝，于是代码变成了：

java复制public PayResult pay(Order order) {
    if ("WECHAT".equals(order.getPayChannel())) {
        String prepayId = wechatPayClient.createPrepay(order.getOrderNo(), order.getAmount());
        return PayResult.success(prepayId);
    } else if ("ALIPAY".equals(order.getPayChannel())) {
        String tradeNo = alipayClient.precreate(order.getOrderNo(), order.getAmount());
        return PayResult.success(tradeNo);
    }
    throw new UnsupportedOperationException("未知支付渠道");
}

第三次，业务方说我们要接入银行卡支付。这次同样是加一个else if。但就在这个时候，一个隐藏问题爆发了——微信支付那边有个特殊逻辑，金额大于5000时需要单独申请大额预支付。这个逻辑在if里，没有人动它，可是因为这次改动导致整个OrderService类重新编译、重新打包、重新发布，结果在发布窗口期，一批微信支付的大额订单被拦截了。原因很隐蔽：发布过程中配置中心有一个临时变更，加上新功能引入了对旧数据兼容的判断bug。这口锅最后说不清到底是谁的，但所有参与者都明白，老代码每被改一次，线上就多一分不确定性。

3.2 重构：把加支付渠道变成"按个开关"

那次事故之后，我们痛定思痛，决定按OCP的思路重构支付模块。设计上我们做了三件事。

第一，定义一个统一的支付渠道接口。接口里抽象出调起支付、查询订单、处理回调、退款这四个最核心的能力。不管什么支付渠道，只要实现这四个方法，就算接入完成。

java复制public interface PaymentChannel {
    String channelCode();
    PayResult createPayment(PayRequest request);
    PayQueryResult queryPayment(String orderNo);
    void handleCallback(CallbackRequest request);
    RefundResult refund(RefundRequest request);
}

第二，每个渠道一个独立实现类，互不干扰。

java复制@Component
public class WechatPaymentChannel implements PaymentChannel {
    @Override
    public String channelCode() {
        return "WECHAT";
    }

    @Override
    public PayResult createPayment(PayRequest request) {
        // 微信支付具体的调起预支付逻辑
        return null;
    }
    // 其他方法略...
}

@Component
public class AlipayPaymentChannel implements PaymentChannel {
    @Override
    public String channelCode() {
        return "ALIPAY";
    }
    // 支付宝具体的预下单逻辑
}

第三，OrderService里不再维护具体的if/else，而是通过Spring注入一个渠道列表，转成Map，按channelCode路由。

java复制@Service
public class OrderService {
    private final Map<String, PaymentChannel> channelMap;

    public OrderService(List<PaymentChannel> channels) {
        channelMap = channels.stream()
                .collect(Collectors.toMap(PaymentChannel::channelCode, c -> c));
    }

    public PayResult pay(Order order) {
        PaymentChannel channel = channelMap.get(order.getPayChannel());
        if (channel == null) {
            throw new UnsupportedOperationException("未知支付渠道: " + order.getPayChannel());
        }
        return channel.createPayment(PayRequest.from(order));
    }
}

重构之后，OrderService这个核心类的支付方法从原来十几行不断膨胀的if/else，简化成了一个稳定的路由逻辑。之后再接新渠道，比如京东支付，只需要新建一个JdPaymentChannel类加上@Component注解，老代码一行都不碰。

3.3 重构前后的量化对比

这里我整理了一个表格，方便大家直观地看到差别：

这个表格不是纸上谈兵。重构之后我们团队经历了两次新渠道接入，每次都是从创建类到联调完成只需要半天，而且不需要碰OrderService的人心里都有底，不用担心把微信支付弄坏。这大概就是OCP能带来的最直接的体感。

3.4 另一种更灵活的变体：策略工厂+动态配置

有些场景下，渠道列表不是启动时就固定的，而是希望运行过程中能动态启停。比如大促期间关闭某条支付通道、或者灰度期间只对部分用户开放某个渠道。这个时候可以在策略模式基础上加一个工厂类，由工厂负责读取配置中心的开关状态，决定返回哪个策略实例。

我实践里的做法是维护一个ChannelRouter，它的核心逻辑是：先从配置中心拉取一个启用的渠道列表，然后拿着请求里的channelCode到channelMap里找实现，如果该渠道在启用列表里就返回实例，否则返回无此渠道。这个Router本身也是一个变化的"业务点"，但它集中在少数几个类里，而不是散落在各处。

这样设计的扩展性更强，因为新渠道的接入仍然是加类加配置，但老渠道的启停也被纳入了动态管理的范围。不过要提醒一句，动态配置会引入额外的一致性风险，你需要考虑清楚配置变更与新建渠道实例之间的竞态问题，否则可能出现配置说启用了、但Spring容器里根本没这个bean的情况。具体的取舍，我在后面第5章还会展开讲。

4. 适当收手：OCP不是过度设计的牌照

4.1 永远正确但不落地，就是空谈

我见过最让人头疼的情况，不是不遵循OCP，而是把OCP当成一块"免死金牌"，所有地方都被抽象成了天马行空的样子。一个只有一种支付渠道的项目，也强行做一个PaymentChannel接口，然后断言"我们遵循了开闭原则"。这种设计就是典型的过度设计，它用复杂度换来了并不存在的扩展性。

OCP真正要对抗的是"频繁变化的业务类型"。如果某个业务维度在可见的未来里根本没有多个实现的可能性，你就不需要为它预留抽象层。比如你现在只支持一个数据库MySQL，就没必要写一个Database的接口，然后搞一个MysqlDatabase、OracleDatabase、PostgresDatabase的实现类。省省吧，这个抽象很大概率永远用不上，而且每次看代码都要多一层跳转，对维护者而言是实实在在的负担。

我给自己定的一个规矩是"三振出局"原则：同一个地方的业务类型分支，出现一次，忍；出现两次，留意；出现第三次，才动手抽象。过早的设计是在赌未来，而赌未来往往输多赢少。

4.2 什么时候真正值得引入扩展点

如果说"三振出局"是保守的判断标准，那么下面这几个信号出现时，可以考虑把OCP的引入时机提前。第一种信号是：产品方已经明确告诉你下个季度会有三种新的业务类型接入。这种情况下今天的抽象就是明天的低成本，该做。第二种信号是：你已经看到了一个反复横跳的模式，比如每个迭代都在给同一个方法加if分支，每次加完还要全量回归，那你就是在为OCP的引入做铺垫，应该立刻动手。

第三种信号则更微妙：你需要多个团队并行开发。如果你有一支团队负责核心订单链路，另一支团队负责外部渠道对接，那么在核心链路中预留稳定接口、让渠道团队独立开发，就不是为了代码美感，而是为了团队并行效率。这种情况下OCP不是可选项，而是协作上的刚需。

4.3 识别"伪抽象"：抽象后反而更难改

还有一个容易踩的坑是抽象层的边界切错了。曾经见过一个项目，把订单和退款两个维度强行拧到一个叫TradeService的接口里，订单相关的操作和退款相关的操作全往里边塞。结果新需求给订单加了一个拆分逻辑，你发现自己要看懂这个方法得先穿过整个TradeService的所有实现类，改起来比之前的大if/else还痛苦。

判断抽象是否合理，不要看接口方法多不多，而要看它是否围绕"单一变化点"展开。如果接口里的方法各自服务于不同的业务变化点，那这个抽象就是失败的。我用一个直白的标准检验：当我提出一个需求时，我能不能只新增一个类，或者只修改一个实现类，就能完成需求而不碰其他无关实现？ 如果答案是"不行，我还要在其他几个实现类里同步改动"，那说明抽象粒度不对，相当于把不相关的变化点焊在了同一个接口上。

比如上面那个TradeService，如果把订单和退款拆成两个接口，订单需求就只动订单实现，退款需求就只动退款实现，互不干扰。OCP的"关闭修改"在拆开之后才真正成立。

5. 团队落地OCP的常见坑：我从报警短信里学到的排查经验

5.1 接口爆炸：抽象粒度太细反而锁死扩展

有一次我们做营销活动的需求，营销规则这块，团队同事特别积极，一口气抽象了七八种策略接口：满减策略、折扣策略、返现策略、秒杀策略、拼团策略…… 本来初心是好的，想让每种策略都独立演化，结果发现这些策略之间有很多交叉逻辑，比如满减和折扣都需要计算优惠门槛，返现和满减都需要校验用户风控等级。为了在这几个策略之间共享逻辑，同事只能在接口里加default方法，结果default方法越加越多，最后每个实现类都要小心翼翼地不触碰到其他策略的默认逻辑。

这给我的教训是，抽象粒度的切割不能跟着业务名词走，而要跟着变化点走。满减、折扣、返现这些是业务分类，不是技术抽象。它们在计算优惠、触发条件、叠加规则等维度上有不同的变化频率。你要抽象的是"优惠计算方式"这个变化点，而不是"满减"这个具体业务。如果你一不小心把所有业务分类都做成策略接口，后期你会发现每次新增一个交叉规则，你要同时改五个策略的默认方法，老代码没少改，OCP自然就破功了。

5.2 看似加了接口，实则框死在抽象类里

还有一种很隐蔽的"伪OCP"：把核心逻辑写在一个抽象类里，然后所有策略都继承这个抽象类。看起来子类各自独立，新需求来了加一个子类就行，但问题在于抽象类里的公共方法本身就承载了大量具体逻辑，一旦某个策略需要微调，子类重写这个公共方法时，很容易就把自己隔离在公共逻辑之外，导致行为不一致。

真正稳定的抽象类，里面的公共方法应该只包含"不变的算法骨架"或者"通用的工具逻辑"，而不是包含某个策略独有的业务规则。如果你发现两个不同的子类都重写了同一个父类方法，而且重写内容差别很大，那这个方法就不该放在父类里，它是变化的点，应该上浮到接口层，由每个实现各自负责。

这种重构做起来很烦，因为它意味着你之前的设计方向错了，需要推倒重来。但趁早调整永远比让错误在代码库里蔓延要便宜。我在项目里是这么约定的：抽象类里不允许包含任何与具体策略强相关的业务判断，只能包含框架性的流程或者被所有子类确认为一致的工具方法。 这条约定执行下来，公共逻辑崩坏的频率低了很多。

5.3 动态配置与OCP的结合：别把配置中心当成万能药

很多团队在使用Spring Cloud或者自研微服务框架时，喜欢把策略的启停、路由规则都扔到配置中心，希望做到运行时不发版就切换渠道。这个思路本身是对的，但落地的时候我踩过不少坑。

最大的问题在"配置与代码的一致性"。有一次我们想在下班后临时停用某条支付渠道，就通过配置中心把channel-status改成了disabled。结果发现渠道虽然停了，但后续该渠道的退款回调还在进来，因为退款的回调处理逻辑并没有经过我们设置的这个开关，它走的是另一套路由。这就是典型的"开关没覆盖所有流程"导致的意外。配置中心不是银弹，它只是把"变化点"从代码迁移到了配置，前提是你必须把变化点定义得足够清晰，覆盖面足够完整。

另外，配置驱动还有一个"隐形陷阱"：当配置成了扩展的手段，很多同学就开始偷懒，把大量的业务规则也写进配置里，比如把复杂的运费计算公式直接拼成表达式挂在配置中心。结果配置越来越长、越来越难维护，出了问题既不能在代码里断点调试，也不能做单元测试，排查效率极低。我现在的原则是，配置里只放"选择哪个实现"的信息，不放"实现的具体逻辑"。 这一切换，复杂度的控制就回到了代码层，配置层的责任相对简单，出问题的概率大幅下降。

5.4 给团队的OCP验收清单

按照我的实践经验，我整理了一份OCP落地后的自检清单，每个新功能或者每次重构提测前过一遍，能过滤掉大多数"假开闭"的问题：

• 核心业务流程的类（比如OrderService）是否保持稳定？本次需求是否完全没有改动它？
• 新功能是否是通过新增类、新增接口实现来完成的？
• 新加入的实现类是否只依赖抽象接口，没有去依赖其他具体实现类？
• 如果本次需要修改某个实现类，这个修改是否只影响这个实现类自身的逻辑，不会波及其他实现？
• 是否有测试用例覆盖了"新增实现不影响老实现"这个场景？
• 是否因为追求抽象而引入了过多的跳转，导致代码的可读性明显下降？

如果这些问题大部分都是"是"，那你的OCP基本落地成功。如果出现很多"否"，建议回头审视一下设计和需求的距离，可能你正在把OCP做成过度设计。

5.5 排查实录：一次"看似遵循OCP"的线上事故

放到最后讲一个我亲身经历的线上事故，很有代表性。某次营销系统做了一次眼睛能看到的"正确重构"，把一个原先耦合在核心流程里的优惠券发放逻辑抽成了策略接口，各种优惠券类型各自实现。因为设计得很礼貌，上线之后功能一切正常。结果运行了一周后，有用户投诉说某个老的活动优惠券突然不发券了。

排查下来发现原因很意外——这次重构改动了一个公共的工具方法，把原先一个基于日期字符串的比较逻辑改成了基于LocalDate的解析逻辑。大多数券种都用了新的工具方法，和新的日期解析逻辑兼容，但那种老活动券的创建日期格式特殊，LocalDate解析直接抛异常，被全局异常处理器吞掉了，看起来就是"没发券"。

这个事故本身不是OCP的锅，但它的教训特别适合放在OCP语境里说：当我们把策略抽出去之后，很容易让各个策略"各自为政"，而忽略策略与策略之间共享的基础逻辑（工具类、校验规则）的一致性维护。 所以哪怕你真正做到"新增实现类、不改核心流程"，公共工具方法的改动同样要格外小心，而且一定要设计好正交测试，确保所有的策略实现都能跑一遍公共逻辑的回归。

从那之后，我们团队约定：任何工具方法被两个以上策略共享时，改动之前必须先拉出所有使用方清单，并且在评审里明确说明"这次改动会影响哪些策略"。

6. 我的个人体会与一个想送你的小技巧

开闭原则真不是背下来就能用的理论，它需要在一次次线上事故和重构里慢慢长成肌肉记忆。我现在带着团队做技术评审，看到新需求的第一反应不是"怎么写"，而是"这是新增还是修改"。如果答案偏向"修改核心流程"，我会本能地追问一句：这个分支为什么不能做成独立策略？这个动作已经帮团队避免了好几次潜在事故。

最后我再分享一个我个人的小技巧。日常写代码时，每当我发现自己在一个核心类里加了新的if/else，我会刻意停下来，问自己三句话：这个分支是稳定存在很久的老分支，还是新增业务分支？这个新增分支如果抽成独立策略，会不会让老分支的风险更小？如果未来再来一个类似分支，我会不会后悔现在的决定？这三句话问完，大部分情况下，我会选择抽出接口去实现。它不是万能公式，但它真的帮我省下了很多原本要熬夜排查问题的精力和睡眠。