企业官网建设流程全解析

1. 为什么你的第一反应是继承

1.1 继承的“知识诅咒”：来自教科书和面试题的惯性

一说起面向对象，很多人脑子里跳出来的第一句话就是“封装、继承、多态”这三大特性。这门课从大学讲到培训，从面试题卷到项目复盘，似乎不会写点extends就不算懂 OOP。再加上面试时又特别爱问“什么是继承”，于是大量开发者形成了一种肌肉记忆：只要看到多个类之间有公共字段或公共方法，第一反应就是抽一个父类出来，然后让子类去继承。

这种惯性本身不是错，但问题是，很多人把继承当成了默认选项，而不是众多选项之一。一旦默认选择了一个成本昂贵的方案，后面所有的代码就都要为这个选择买单。尤其是做业务系统的时候，需求是持续变化的，今天你抽好了一个基类，明天产品加一个“既要 A 又要 B”的需求，继承体系立刻开始别扭。

我印象很深的一次代码评审，是一个订单流程的模块。成员写了一个BaseOrderProcessor，然后EmailOrderProcessor、SmsOrderProcessor、ApiOrderProcessor都去继承它。当时看起来挺整齐：公共的校验逻辑放基类、公共的日志埋点放基类、子类各自实现自己的发送逻辑。结果第二周需求来了：订单创建后要同时发短信和邮件，微信服务号消息也要推。这一下就卡住了——Java 是单继承，你没法让一个类同时继承EmailOrderProcessor和SmsOrderProcessor。最后怎么解决的？有人提议再加一层EmailAndSmsOrderProcessor extends EmailOrderProcessor然后把短信逻辑复制过来，有人提议把发送逻辑改成接口，还有人提议找个多继承的语言来重写。听起来很荒诞，但这种场景在真实项目里每天都在发生。

继承的诱惑在于它看起来很优雅，公共逻辑集中了、子类代码精简了、类之间的关系一目了然。但它的代价恰恰也隐藏在这种优雅里：一旦继承层级固定下来，整个体系就变成了一张难以挣脱的网。你越想复用公共代码，就越会把子类绑死在父类的行为上；你越想扩展新能力，就越容易发现父类手上的东西根本不是你想要的。

1.2 继承的暗面：脆弱的基类与功能交叉爆炸

很多人在面试时能把继承的语法背得滚瓜烂熟，什么方法重写、构造器调用顺序、super关键字，张嘴就来。但真正让人挠头的不是语法，而是继承体系在持续迭代中的崩溃。

先说说“脆弱的基类”问题（Fragile Base Class）。父类一旦发布，子类就对父类产生了强依赖。父类改一个方法的内部实现，所有子类都可能受到影响。你以为只是优化一下公共逻辑，结果跑测试发现三个业务模块的行为变了。更麻烦的是，有些影响是隐性的——父类里一个protected字段被某个子类直接用了，你改了字段语义，那个子类不会报编译错，但运行结果已经不对了。这类问题的排查成本往往非常高，因为你不会第一时间怀疑父类，而会在子类的业务逻辑里翻半天。

再往深一层说，就是功能交叉爆炸。继承适合描述“树状”的层级关系：猫是动物，狗是动物。但业务需求从来不按树状生长，它更像一张网。拿报表导出举例，假设你先有 Excel 导出和 PDF 导出，于是抽了一个BaseExporter，两个子类各自实现导出逻辑。后来需要给导出文件加密，你加了EncryptedExcelExporter和EncryptedPdfExporter。再后来需要加水印，你又加了WatermarkedEncryptedExcelExporter、WatermarkedEncryptedPdfExporter。这时候你会发现类数量开始失控：导出格式有 2 种、附加能力有 2 种，组合出 4 个类你还能接受；当格式变成 5 种、附加能力变成 4 种时，继承体系需要创建的类数量是5 x 2^4 = 80个。这就是组合数学里的指数增长问题，只不过很多人写代码时意识不到自己在不知不觉间制造了一棵“类爆炸”的树。

这种问题在工具链里也会遇到。比如 PCB 设计工具 Allegro 的规则管理器里，net class 在设计之初看起来很适合用继承去复用间距规则，但实际工程里到处是“net 的 class 不能继承”“父 class 改了子 class 没跟上”的抱怨。为什么会这样？因为规则之间天然是多重归属的：一条网络既要满足高速信号的阻抗要求，又要满足板厂的最小间距要求，还要满足电源网络的载流要求。如果你用继承去表达这些规则，就等于逼着一条网络只能有一个“父亲”，这跟实际设计需求完全拧着来。最后大家只能用组合的方式，把不同维度的规则打包成 rule set，再分配到具体网络上。这个案例我印象特别深——它说明“继承表达不了交叉归属”这件事，在软件之外的世界里也一样成立。

你可能会想，这些问题是不是因为我设计得不好？确实，好的继承设计能把这些问题弱化一些，但很难根除。因为继承的核心假设是“子类是一个父类”，是严格的 is-a 关系。而真实业务里，绝大多数需求是 has-a 和 can-do 的关系，比如“订单处理器有短信发送能力”“报表导出器可以做加密处理”。一旦你强行用 is-a 去表达 has-a，设计就扭曲了。

2. 组合到底解决了什么问题

2.1 组合的本质：把能力当成可插拔的零件

如果说继承是在回答“我是什么”，那组合就是在回答“我有什么”。组合的思路是：一个对象不需要通过继承来获得某种能力，它可以持有具备该能力的对象，然后在合适的时机调用它。这两种思路的差别，刚开始写代码的时候感受不到，等你需要改需求、加功能、做单元测试的时候，差距就全部暴露出来了。

组合的本质可以类比成模块化硬件。你的电脑需要图形处理能力，你没有把 GPU 电路“继承”到主板上，而是插一块独立显卡上去。显卡想升级，直接换新卡，主板不用动；显卡坏了，换张卡就行，CPU 和内存照常工作。如果你用继承的思路造电脑，那每一代新电脑都得从上一代“派生”出来，CPU、内存、显卡焊死在一起，换个显卡等于换台电脑。组合带来的好处就是这个：零件之间解耦，每个零件可以独立替换、独立升级、独立测试。

反映到代码上，组合让类与类之间的关系变得松散。一个类持有哪些依赖，就决定了它有哪些能力。想发短信，注入一个SmsSender；想发邮件，注入一个EmailSender；想两个都发，注入两个对象。类的职责边界清清楚楚，新增能力不需要去动已有的类。这正好跟面向对象设计里那条著名的“开闭原则”对上——对扩展开放、对修改关闭。继承体系想扩展新能力，往往要新增子类，甚至改动父类；组合体系想扩展新能力，只要新增一个零件类，然后在装配的地方换一下即可。

2.2 为什么说“继承是静态的，组合是动态的”

继承的关系在编译期就固化了，子类能用什么、不能用什么，写代码的那一刻就已经定死。组合的关系则是在运行期确定的——一个对象可以注入什么依赖，完全由运行时装配决定。

这种静态和动态的差异，在日常维护中非常致命。举一个真实的场景：前端要做一个下拉框，后端的同学可能觉得下拉框就是“继承”自某个Select组件，然后在子类里覆盖渲染方法。但前端同学写久了就会知道，实际页面上那些看着像下拉框的东西，很多根本不是原生<select>，而是<div><ul><li>组合出来的自定义组件。为什么放着原生组件不用，非要自己组合一个？

因为原生的下拉框行为是“继承”好的：它的样式、交互、弹出方式都由浏览器定死了。你想给选项加个小图标？想支持多级联动？想在出现长列表时做虚拟滚动？这些需求在原生组件里要么做不到，要么得 hack。而<div><ul><li>的组合方案，每一个层次都是一个独立的零件：容器管布局、列表管滚动、列表项管渲染色块和文本。想要什么行为，就像搭积木一样组合进去。Selenium 去定位这种自定义下拉框的选项时也特别直观，先找到那个div，再到ul里找li，一层一层往下走，每一步都可控。

组合的动态性还体现在运行时行为切换上。策略模式是靠组合实现的经典例子：一个OrderProcessor持有FeeCalculator接口，运行时根据用户等级注入普通价格计算器、会员价格计算器或促销价格计算器。这种切换在继承体系里几乎无法实现——你不可能在运行时改变一个对象的父类，但你可以随时换掉对象内部持有的策略实现。很多复杂系统就是要靠这种“运行时换脑子”的能力，才能支撑那么多动态的业务逻辑。

再往深了说，这种“把行为拆开再组合”的思路不止适用于代码。做过导航系统的人都知道，现在主流的惯性导航+卫星导航组合导航方案，本质就是一个“组合优于继承”的工程案例：惯性导航系统短时精度高、数据连续，但长时间会漂移；卫星导航有绝对参考、误差不累积，但信号容易被遮挡。你让任何一个系统“继承”另一个系统的全部特性都很别扭，所以工程上干脆把它们当作两个独立的传感器，做数据融合，用组合的方式发挥各自优势。硬件电路里 JFET 加 BJT 组合成 cascode 放大电路，也是类似的道理——把两种器件各自的优点组合起来，而不是试图把两种器件“继承”成一个。这种思维方式跨行业通用：说不清谁是谁的父类时，就考虑让它们协作。

3. 什么时候仍可以继承：组合不是银弹

3.1 判断标准：真正的 is-a 关系 + 稳定不变的行为

如果组合这么好，那继承是不是应该彻底不用了？也不是。组合是更安全的默认选择，但继承在某些场景下仍然更合适。关键在于你能不能确认两个条件。

第一个条件是严格的 is-a 语义。子类必须能够完全替代父类，并且在任何父类能出现的地方，子类都不会造成语义错乱。经典的例子是Square extends Rectangle，看起来很自然，正方形是一种矩形，对吧？但你一旦给Rectangle设置了setWidth和setHeight两个方法，正方形作为子类就会面临两难：要么破坏正方形的约束，要么重写方法让宽高联动。这个例子被引用了无数次，因为它精准地戳中了“语义看似正确，行为实际矛盾”的困境。反过来说，Circle extends Shape这种就非常安全，因为圆形确实不需要重写什么约束。

第二个条件是行为稳定不变。如果父类的行为在未来大概率不会变化，子类也大概率不会因为需求迭代而分化，那用继承把公共代码集中起来是划算的。比如定义一个BaseEntity，里面有id、createdAt、updatedAt这些所有表都有的字段，还提供equals、hashCode、toString的统一实现。这种基类几乎不会变，也不存在行为交叉问题，用继承非常合适。

这两个条件同时成立的时候，继承是高效且清晰的。问题在于很多开发者只看到了“语义看起来像 is-a”，忽略了对稳定性的判断。你抽一个BaseOrderProcessor的时候，真的能保证订单处理逻辑一年内不变吗？显然不能——订单流程恰恰是业务上变化最频繁的部分。所以我的建议是：抽继承之前，先问自己一句“如果产品明天让这个类的行为完全变个样，我的设计还撑得住吗？”撑不住，就老老实实走组合。

3.2 组合与继承混用的正确姿势

现实项目里几乎不存在“纯组合”或“纯继承”的代码，大部分好的设计是两者混用，关键是混得合理。

先说接口加组合这套组合拳。Java 里类的继承只有单继承，但接口可以实现多个。很多人没有意识到接口本身就是一种轻量级的“类型继承”替代品：一个类implements A, B, C，本质上就是在声明它同时具备 A、B、C 三种类型身份。配合接口默认方法（default method），Java 8 之后你甚至可以在接口里提供一部分默认实现。但接口的优势不在于复用代码，而在于定义契约。组合负责持有能力对象，接口负责约束能力对象的形状，两者配合，既松耦合又不失规范。

再说模板方法模式。这个模式本身就是基于继承的，父类定义算法骨架，子类填充具体步骤。比如数据迁移任务，从数据库 A 抽取数据、做清洗、写入数据库 B，整个流程的顺序是固定的，但清洗逻辑因数据源而异。这种场景用继承的模板方法模式非常舒服：DataMigrationTask里定义run()方法，内部依次调用extract()、clean()、load()，子类只需要实现这三个步骤。但这有一个前提——算法骨架必须真的稳定。如果哪天发现某些任务要先清洗再抽取、某些任务要加一个校验步骤，模板方法就会变成“模板崩溃法”。所以模板方法模式适合用在流程固化程度高的场景，但凡流程顺序可能变化，你就应该把每个步骤提取成策略对象，用组合来编排流程。

还有一个特别好的混用案例是装饰器模式。BufferedInputStream的源码就是用组合实现的，它内部持有另一个InputStream，并在读数据时加上缓冲逻辑。同样是给一个对象附加能力，装饰器用的是“包一层组合对象”，而不是“生成一个继承子类”。这样做的好处是你可以任意叠加多个能力：先缓冲，再加密，再压缩，每一层都是独立的类。如果是继承方案，给InputStream加缓冲能力你得写一个BufferedFileInputStream，再加密还得写一个EncryptedBufferedFileInputStream，叠加两个能力就要四个类，叠加三个能力就要八个类——这又回到了组合数学的指数爆炸问题。

4. 实战重构：把一套继承设计改成组合设计

4.1 原始继承方案：报表导出器的痛点

前面提到了报表导出场景，我把代码简化一下，带着大家一起看看从继承改到组合的完整过程。

原始继承设计大概是这个样子的：

public abstract class BaseExporter { public void export(String data, String filePath) { validate(data); byte[] content = convert(data); writeToFile(content, filePath); } protected void validate(String data) { if (data == null || data.isEmpty()) { throw new IllegalArgumentException("导出数据不能为空"); } } protected abstract byte[] convert(String data); private void writeToFile(byte[] content, String filePath) { // 省略文件写入逻辑 } } public class ExcelExporter extends BaseExporter { @Override protected byte[] convert(String data) { // 把数据转换成 Excel 字节流 } } public class PdfExporter extends BaseExporter { @Override protected byte[] convert(String data) { // 把数据转换成 PDF 字节流 } }

这个设计在初期用着还行。两个子类，公共校验逻辑在父类里，子类只负责格式转换。可一旦需求开始交叉，麻烦就来了。

第一个需求是导出文件要加密。你硬着头皮加了一个EncryptedExcelExporter，为了复用原来的转换代码，它得继承ExcelExporter。但这时候父类BaseExporter的export方法里没有加密的步骤，你只能在EncryptedExcelExporter里重写export方法，把加密逻辑塞进去，然后再调用super.export。第二个需求是 PDF 加水印，你照葫芦画瓢写了一个WatermarkedPdfExporter。第三个需求来了：Excel 也要加水印。这时候你发现同一个水印逻辑没法同时被两个不同父类的子类复用，因为EncryptedExcelExporter和WatermarkedPdfExporter没有血缘关系。

我见过项目里最夸张的情况，是有人为了处理这种交叉需求，把代码复制粘贴了三遍，然后被代码评审骂得狗血淋头。其实问题根源不在于团队成员偷懒，而在于继承这个基础设计把大家逼到了墙角——任何横切能力都找不到合适的地方放。

4.2 重构后的组合方案：策略加装饰器加工厂

重构的思路很明确：把“导出格式”和“附加能力”拆成两个维度的零件，让它们可以独立组装。格式转换是策略，加密、水印、压缩是装饰能力，组装过程交给一个简单工厂控制。

首先定义格式转换策略接口：

public interface DataFormatter { byte[] format(String data); } public class ExcelFormatter implements DataFormatter { @Override public byte[] format(String data) { // 把数据转换成 Excel 字节流 return new byte[0]; } } public class PdfFormatter implements DataFormatter { @Override public byte[] format(String data) { // 把数据转换成 PDF 字节流 return new byte[0]; } }

然后定义装饰器基类，它本身也实现DataFormatter，但它持有一个被包装的DataFormatter：

public abstract class FormatterDecorator implements DataFormatter { protected final DataFormatter wrapped; public FormatterDecorator(DataFormatter wrapped) { this.wrapped = wrapped; } } public class EncryptedFormatter extends FormatterDecorator { public EncryptedFormatter(DataFormatter wrapped) { super(wrapped); } @Override public byte[] format(String data) { byte[] original = wrapped.format(data); // 对 original 做加密处理，返回加密后的字节流 return encrypt(original); } } public class WatermarkedFormatter extends FormatterDecorator { public WatermarkedFormatter(DataFormatter wrapped) { super(wrapped); } @Override public byte[] format(String data) { byte[] original = wrapped.format(data); // 对 original 加水印，返回处理后的字节流 return addWatermark(original); } }

组装类就是一个简单的导出服务：

public class ReportExportService { public void export(String data, String filePath, ExportOptions options) { DataFormatter formatter = createFormatter(options); byte[] content = formatter.format(data); writeToFile(content, filePath); } private DataFormatter createFormatter(ExportOptions options) { DataFormatter formatter = new ExcelFormatter(); // 默认 Excel if (options.getFormat() == ExportFormat.PDF) { formatter = new PdfFormatter(); } if (options.isEncrypted()) { formatter = new EncryptedFormatter(formatter); } if (options.isWatermarked()) { formatter = new WatermarkedFormatter(formatter); } return formatter; } private void writeToFile(byte[] content, String filePath) { // 文件写入逻辑 } }

重构之后，你会发现几个肉眼可见的变化。第一，新增一种导出格式，只要实现DataFormatter接口，不需要动任何已有类。第二，新增一种附加能力，只要实现一个FormatterDecorator，由调用方决定是否要装饰、装饰顺序如何。第三，所有附加能力都是可叠加的，加密加水印、加密加压缩、压缩加水印，想怎么组合就怎么组合，类数量从指数爆炸变成线性增长。

这个模式的本质是策略模式加装饰器模式，而这两个模式都建立在组合之上。写测试也变得非常舒服：想测加密逻辑，就new EncryptedFormatter(new ExcelFormatter())，单独隔离测试；想测水印逻辑，就new WatermarkedFormatter(new PdfFormatter())。不需要像继承方案那样构造一堆类的实例，也不需要为了覆盖某个方法而创建匿名子类。

这里补充一个细节：重构的过程中，validate校验逻辑去哪了？我没有放到装饰器链里，而是在ReportExportService.export的开头直接判断。因为校验是所有导出流程的公共前置步骤，本质上是一个稳定的流程节点，不适合作为可插拔的能力参与装饰组合。用继承方案时它放在BaseExporter里，用组合方案时它放在编排服务里，作用是一样的。这个细节想说明一件事：组合不是要消灭所有公共代码，而是让你有更强的能力去选择公共代码该放在哪里。

5. 常见问题与排查技巧实录

5.1 “组合以后代码变碎了”的心理门槛

最常见的反对意见是：继承方案里类很少，每个类一目了然；组合方案里满屏都是小接口、小类，项目文件数量暴涨，看着心惊肉跳。

这种感受我完全理解，但它通常是被 Eclipse 和 IDEA 左边那个项目树吓出来的。组合方案的文件确实更多，但每个文件的职责边界也更清晰，真正的复杂度并没有增加，而是从“类继承关系的复杂度”转移成了“对象装配关系”。继承体系有一个显著的假象：类数量少，看着干净。可一旦你点开代码，会发现一个类几百上千行，子类之间的绕行逻辑让你晕头转向。组合体系恰好反过来，每个类都很短，真正的复杂度集中在创建对象、装配依赖的那几个工厂类和配置类里。

应对建议是：不要用类数量衡量设计好坏，而要用修改成本衡量。问自己一个问题：产品提一个新需求，我需要改几个类？继承体系下你可能要新增两个子类再改一个父类；组合体系下你可能只要新增一个类、改一行装配代码。后者虽然文件变多了，但你每次改动的范围明显收窄了。任何一个维护过半年以上项目的开发者，只要尝到过“小改动不惊动全线”的甜头，都不会愿意退回继承方案。

5.2 对象生命周期与共享状态问题

组合方案里，一个对象会持有多个依赖对象，这些依赖对象的创建和销毁需要管理好，否则容易出现生命周期不一致或者状态共享导致的隐蔽 Bug。

先说生命周期。如果ReportExportService是单例，那它持有的DataFormatter通常是无状态的，可以安全地作为单例注入。但如果某个DataFormatter内部有可变的缓存或者计数器，单例部署就会出问题。解决思路两个方向：要么保证组件无状态，把可变状态作为方法参数传递；要么不使用单例，每次使用时都通过工厂创建新的对象实例。很多人踩的第一个坑就是把有状态的组件当无状态组件用，然后线上出现“这次导出带了上次导出的水印”这种诡异问题。

共享状态问题更隐蔽。假设你在WatermarkedFormatter里设计了一个类级别的LOGO常量，这没问题；但如果你不小心写了一个实例级别的watermarkPosition字段，而多个导出请求共用了同一个formatter实例，那请求 A 改了位置，请求 B 就跟着变了。这种问题的排查非常耗时，因为代码逻辑本身没错，错在对象被多线程共享了。我的经验是：组合体系里的组件默认都按无状态设计，凡是实例字段都要慎重再慎重，非要有状态就显式注明并要求调用方保证隔离。

调试时推荐一个技巧：给组合对象写一个清晰的toString()方法，把各个组件的类型和关键状态打出来。这样你在断点或者日志里一眼就能看到“这个对象包了哪些层、每一层是什么类型”，排查装配问题会快很多。IDEA 的调试器也能拉出对象内部结构，但一个友好的toString()在线上日志排障时价值更大。

5.3 组件之间怎么通信，绕来绕去改不动

组合方案的另一个常见问题是：组件之间需要互相调用，直接持有对方引用会让耦合重新升高。

最典型的场景是：导出文件时，加密组件需要知道目标文件的版本信息，而版本信息在导出服务里才有。如果你在EncryptedFormatter里直接注入ReportExportService，两边就产生了环状依赖，组合的优势瞬间消失。解决办法是抽象出上下文对象，让组件之间的通信通过上下文传递。

public class ExportContext { private String fileName; private String version; private Map<String, String> metadata; // getter / setter 省略 }

每个组件的format方法除了接收原始数据，再接收一个ExportContext，需要什么信息就从上下文里取。这样组件与组件之间完全不直接依赖，都只依赖上下文这个“共享内存”。这是组合方案面对复杂协作需求时的标准解法，也是我最想强调的实战经验——组合只解决“需要什么能力”的问题，组件之间“如何协作”还要靠上下文或事件机制单独设计。

很多人把“组合优先于继承”理解成“把类拆得越碎越好”，这其实是个误解。组合优先的真正含义是：优先用对象之间的协作关系来表达能力和扩展，而不是用类之间的继承关系来表达。拆碎只是手段，协作才是目的。如果你的组合方案里组件之间耦合紧密、通信全靠直接互相 new，那还不如回到继承，起码继承的层级关系还自带一定的可读性。

最后再分享一个小技巧：在代码评审的时候，我习惯先看这个类有没有父类。如果有父类，我会问三个问题——子类重写了父类的方法吗？重写的方法有没有调用super？父类的方法有没有被所有子类共用？如果答案都是否，那大概率是不该用继承的。如果这个类有组件字段，我会看这些组件能不能独立替换、独立测试。能，那这个组合就用得对。这套判断标准我用了很多年，几乎每次评审都能帮团队提前发现几个会演变成重构难题的继承设计。