企业官网建设流程全解析

"类的继承"这个话题，我在不同项目里反复碰见，也反复踩坑。不管是刚学Java的大学生，还是写了几年业务代码的工程师，只要涉及面向对象设计，就绕不开继承。这篇笔记我自己整理了很久，不打算讲教科书上那套抽象理论，而是把真正用得上、容易错的东西写出来。如果你正在学类与继承，或者写代码时对父类子类的设计拿不准，这篇基于真实工作经验的拆解应该能帮到你。

1. 继承到底解决了什么问题

1.1 从代码复用聊起：继承的本质

很多人一提到继承，第一反应就是"子类复用父类的代码"。这话没错，但只说对了一半。继承真正解决的是类型关系上的抽象问题，代码复用只是它捎带手带来的好处。

我举个生活化的例子。假设你是一家餐厅的老板，你现在有三种员工：后厨厨师、前台收银员、传菜员。这三类人都有共同的特征——都有工号、都有姓名、每个月都要发工资。如果你分别定义三个完全独立的类，工号和姓名这两个字段就得写三遍，发工资的方法也得写三遍。这不是不行，但只要你改一下工资的计算规则，就得同时改三个地方，漏改一个就出bug。

这时候继承就派上用场了。你定义一个Employee父类，把工号、姓名、发工资这些公共的东西放进去，然后让Chef、Cashier、Waiter三个子类去继承它。子类只需要写自己特有的东西，比如厨师特有的"菜品评分"，收银员特有的"收银差错率"。这样一来，公共逻辑只维护一份，改工资规则只改父类，三个子类自动生效。

我在实际项目里常用的判断标准是：如果两个类之间不是"is-a"（是一个）的关系，就不要硬用继承。厨师是一个员工，所以厨师继承员工没问题。但"餐厅"和"厨师"之间是"has-a"（有一个）的关系，餐厅包含厨师，这种关系就该用组合而不是继承。很多设计混乱的代码，根源就是把is-a和has-a搞混了。

1.2 什么时候该用继承，什么时候别硬凑

我自己总结了一套判断原则，不一定适合所有人，但实测下来能避免不少后期重构的麻烦。

适合用继承的场景，通常满足这几个条件：

• 子类确实是一个更具体的父类类型，比如Dog继承Animal，逻辑上完全成立。
• 子类需要复用父类的完整实现，并且只做扩展、少做修改。
• 多个子类之间存在大量公共字段和方法，把这些提到父类能显著减少重复代码。
• 你希望在运行时通过父类引用来统一处理一组子类对象，这就是多态的基础。

不适合用继承的场景也很多，比适合的场景更容易踩坑：

• 仅仅为了省几行代码就把两个不相干的类强行挂上父子关系。
• 父类的方法实现对于子类来说大部分都用不上。比如你继承了ArrayList，但你的类根本不需要add方法，这种继承就是过度设计，迟早会在某个调用方手里炸掉。
• 继承层级超过三层。我在工作里见过六层继承的代码，改一个底层方法上面五个层级全受影响，那种感觉就像推倒一张多米诺骨牌，你不知道会倒到哪一张才算完。
• 子类需要大幅重写父类方法的时候。如果每个子类都把父类方法重写了个遍，而且公共代码几乎没有，那说明继承关系本来就是硬凑的，不如各写各的接口。

还有一个特别常见的场景是"工具类要不要继承"。后台开发中很多人喜欢建一个BaseController或者BaseService，把日志、鉴权、参数校验塞进去，然后让所有Controller或者Service继承它。这个思路本身没啥问题，但如果Base类里堆了七八个互不相干的方法，子类实际上只用到了其中一两个，这就违背了继承的初衷。更好的做法是把那些互相独立的能力拆成单独的类，通过组合引用来使用。

1.3 封装、继承、多态：三者是绑定关系

在面向对象的世界里，封装、继承、多态从来不是三个独立的知识点，而是互相依赖的一个整体。网上能搜到大量关于"封装继承多态"的考题，但我发现很多人只是背概念，从来不理解它们为什么非要绑在一起。

封装解决的是"边界"问题。一个类把内部状态藏起来，只暴露有限的方法给别人调用。父类里的private字段，子类也看不到，这个边界意识尤其重要——你在Father类里写了一个private int money，子类想直接用是编译不过的，必须通过protected或者公共的getter才拿得到。

继承解决的是"复用和扩展"问题。子类在父类的基础上继续细化，复用父类已经实现好的能力，再补充自己特有的能力。

多态解决的是"统一处理"问题。因为子类是父类的一种，所以你可以把一堆不同的子类对象塞进一个父类类型的数组里，然后逐个调用同一个方法，每个对象的实际行为由它自己的类决定。

举个经典例子：Animal类有一个speak()方法，Dog重写成"汪汪汪"，Cat重写成"喵喵喵"。你写一个函数，参数类型是Animal，里面调用speak()方法，然后传入Dog对象就打印"汪汪汪"，传入Cat对象就打印"喵喵喵"。这段代码里，封装保证了每个类内部状态不越界，继承保证了Dog和Cat确实是Animal，多态保证了你只需要写一个函数就能处理所有Animal的子类。这三者缺一个，整个设计就转不起来。

2. 核心语法与关键细节

2.1 Java继承：extends、super与重写的边界

Java里实现继承用的是extends关键字，这是Java语法里最直白的一个词。一个类只能继承一个父类，这是Java和C++最大的区别之一，Java故意砍掉了多继承，用接口来弥补。

写一个基本的继承代码如下：

// 父类 public class Animal { protected String name; public Animal(String name) { this.name = name; } public void speak() { System.out.println(name + " 发出声音"); } } // 子类 public class Dog extends Animal { public Dog(String name) { super(name); // 调用父类构造方法 } @Override public void speak() { System.out.println(name + " 汪汪汪"); } }

这里有几个细节值得展开说。

第一，super关键字是子类访问父类成员的通道。在子类的构造方法里，super(name)必须在第一行，这是Java语法强制规定的。原因很实在：你得先把父类部分构造完成，子类的扩展部分才能安全创建。如果允许父类构造在后，子类初始化时用到父类字段就会拿到未初始化的数据。

第二，@Override注解的作用是告诉编译器"这个方法我要重写"。它最大的价值不是给人看，而是给编译器做检查。如果你方法名拼错了，比如把speak拼成sppeak，没写注解的话编译完全通过，你以为是重写，实际上子类悄悄新增了一个方法。一旦写了@Override，拼错了直接编译报错，能把这种隐蔽bug堵在编译阶段。我在开发中有一条几乎强制的规定：凡是重写父类方法，一律必须加@Override注解，否则代码Review直接打回。

第三，protected修饰符在继承场景里非常重要。父类的private字段子类不可见，public又谁都能访问，中间那个档位protected就是专门为继承准备的——子类可以访问，外部其他类不能访问。上面例子里的name字段，如果用private修饰，子类Dog的方法体里直接访问name会编译报错。反过来说，如果什么字段都用public，封装就形同虚设了，外部代码可以随便改你的内部状态。

第四，重写（Override）和重载（Overload）的区别经常被拿来当面试题。重写是子类对父类方法重新实现，方法名、参数列表、返回类型都必须一致；重载是同一个类里多个同名方法，参数列表不同。我见过有人把这两个概念混着说，写代码的时候也容易搞混。简单记：重写发生在父子类之间，重载发生在同一个类内部。

2.2 Python继承：从class Dog(Animal)说起

Python的继承语法比Java更简洁，没有extends关键字，直接在类名后面的括号里写明父类即可。Python还有一个Java没有的能力：支持多继承，一个子类可以同时继承多个父类。

class Animal: def __init__(self, name): self.name = name def speak(self): print(f"{self.name} 发出声音") class Dog(Animal): def __init__(self, name): super().__init__(name) def speak(self): print(f"{self.name} 汪汪汪")

Python版本的继承有两个细节跟Java不同，特别容易踩坑。

第一个坑是super().__init__()。Python的super()不需要显式传入父类名，这一点比Java方便。但这里有个常见的初学者错误：写了Animal.__init__(self, name)而不是super().__init__(name)。第一种写法在单继承下能用，但一旦涉及多继承，硬编码父类名的写法会导致复杂的调用链出问题。super()的作用不只是调父类，而是按照__mro__（方法解析顺序）调下一个类。多继承下，这个顺序搞错了，初始化就会奇奇怪怪地乱跑。

第二个坑是Python的类属性与实例属性。在Python类里，直接写在类体中的变量是类属性，写在__init__里的是实例属性。类属性是所有实例共享的，实例属性是每个对象独立的。这个区别在继承场景里很有迷惑性，比如：

class Parent: items = [] # 类属性，所有实例共享 class Child(Parent): pass a = Child() b = Child() a.items.append(1) print(b.items) # [1]，因为a和b共享了同一个类属性items

这个坑我在实际项目中遇到过。某次定义一个配置类，把列表写成了类属性，结果一个实例修改了配置，其他实例全部跟着变，排查了很久才发现是类属性共享导致的。结论很简单：可变对象（列表、字典、集合）千万不要直接作为类属性定义，除非你有意让所有实例共享。

Python还有几个跟继承相关的工具函数值得掌握，比如isinstance(obj, Class)用来判断对象是否为某个类的实例，issubclass(Child, Parent)判断子类关系，getattr(obj, "method_name")动态获取属性或方法。在写框架代码、反射调用的时候，这三个函数远比硬编码调用更灵活。

2.3 构造方法与初始化顺序：父子类执行的先后坑

不管是Java还是Python，继承场景下的初始化顺序都是个经典问题。Java里更严格，Python里相对灵活，但坑一个都不少。

Java的执行顺序是这样的：

1. 加载父类静态代码块和静态变量初始化。
2. 加载子类静态代码块和静态变量初始化。
3. 执行父类实例代码块。
4. 执行父类构造方法。
5. 执行子类实例代码块。
6. 执行子类构造方法。

我经常看到面试题出这种题，问创建子类对象时输出什么顺序。核心规则就两条：先父后子、先静态后实例。记住这两条，基本不会错。

但实际开发中更有价值的坑是：父类构造方法里调用了被子类重写的方法，会执行子类的方法实现。Java的动态绑定机制决定了，对象实际是子类类型时，任何方法调用都会优先匹配子类的重写版本，哪怕这个调用发生在父类的构造方法里。

public class Parent { public Parent() { init(); // 这里调用的是子类的init() } protected void init() { System.out.println("Parent init"); } } public class Child extends Parent { private int value = 10; @Override protected void init() { System.out.println("Child init, value=" + value); } }

实例化Child的时候，输出结果是Child init, value=0，而不是value=10。原因在于，父类构造方法执行的时候，子类的value = 10还没执行，因为子类的字段初始化发生在父类构造完成后。此时读value，拿到的是Java默认值0。

这个坑我在真实项目中碰到过一次，当时是某个配置加载类，父类构造方法里调用了loadConfig()，这个方法是重写的，结果子类里依赖的字段还没初始化，加载出来全是默认值。后来把字段初始化挪到构造方法里的一个init()方法里，由子类显式调用，问题才解决。

我的一条经验规则：父类构造方法里不要调用可被重写的方法。如果非要调用，就在父类里用private或者final修饰，这样就不会被子类重写，也就消除了动态绑定的意外。

Python的初始化顺序稍微不一样，但核心逻辑一致。super().__init__()保证了父类先初始化，多继承的时候按照__mro__顺序依次初始化。Python还有一个Java没有的特点：Python的__init__不是强制必须调用的，父类的__init__不会被自动调用，必须显式super().__init__()。忘记调用父类初始化方法，子类就访问不到父类在__init__里定义的字段，这个报错信息是AttributeError，遇到这个错先检查是不是漏了super().__init__()。

3. 继承体系设计实操：从UML到代码落地

3.1 用一个真实场景把继承讲透

前面讲的都是语法细节和概念辨析，这一节我来做一个完整的实操案例，从需求分析到类图设计再到代码实现，完整走一遍流程。

假设你要做一个简单的"宝可梦风格"的角色对战游戏。游戏里有多种角色，每种角色有生命值、攻击力、防御力这几个基础属性，攻击的方式各不相同。有些角色可以施放技能，有些角色只能普通攻击。这个需求特别适合用继承来建模，也因为"类宝可梦游戏 源码"是网上很热门的学习项目类型，很多初学者都在找参考。

先做需求整理：

• 所有角色都有名称、生命值、攻击力、防御力。
• 所有角色都能进行普通攻击。
• 部分角色可以施放特殊技能，技能效果各不相同。
• 攻击时需要考虑目标的防御力，计算实际伤害。
• 后续可能新增更多角色类型，比如飞行系、水系、电系。

这个需求如果用继承来设计，思路应该是这样的：

首先定义一个抽象父类Pokemon（宝可梦），把公共属性、公共方法都放进去。

public abstract class Pokemon { protected String name; protected int hp; protected int attack; protected int defense; public Pokemon(String name, int hp, int attack, int defense) { this.name = name; this.hp = hp; this.attack = attack; this.defense = defense; } // 普通攻击，所有角色通用 public void attack(Pokemon target) { int damage = Math.max(1, this.attack - target.defense); target.hp -= damage; System.out.println(name + " 攻击 " + target.name + "，造成 " + damage + " 点伤害"); } // 特殊技能，需要被子类各自实现 public abstract void useSkill(Pokemon target); public boolean isAlive() { return hp > 0; } }

然后定义几个具体子类。比如皮卡丘（电系）、妙蛙种子（草系）、小火龙（火系）。

public class Pikachu extends Pokemon { public Pikachu() { super("皮卡丘", 350, 60, 40); } @Override public void useSkill(Pokemon target) { // 十万伏特，电系技能，伤害较高且无视部分防御 int damage = this.attack + 40; target.hp -= damage; System.out.println(name + " 使用十万伏特，造成 " + damage + " 点伤害"); } } public class Charmander extends Pokemon { public Charmander() { super("小火龙", 320, 70, 30); } @Override public void useSkill(Pokemon target) { // 火焰喷射，火系技能 int damage = this.attack + 30; target.hp -= damage; System.out.println(name + " 使用火焰喷射，造成 " + damage + " 点伤害"); } }

这个设计有个特别重要的优点：战斗系统的核心代码可以和具体的角色类解耦。你写一个战斗管理器，参数类型是Pokemon，不需要判断对方到底是皮卡丘还是小火龙，直接调用useSkill()和attack()就行。

public class BattleManager { public static void startBattle(Pokemon a, Pokemon b) { System.out.println(a.name + " 与 " + b.name + " 的对战开始！"); while (a.isAlive() && b.isAlive()) { a.useSkill(b); if (b.isAlive()) { b.useSkill(a); } } Pokemon winner = a.isAlive() ? a : b; System.out.println("对战结束，胜利者是：" + winner.name); } }

以后新增一个角色，只需要新写一个继承Pokemon的类，重写useSkill方法，然后传入BattleManager就行，战斗系统一行代码都不用改。这就是面向对象设计的好处：扩展靠新增类而不是修改现有代码，也就是开闭原则（对扩展开放，对修改关闭）。

3.2 用类图把继承关系画清楚

代码写之前，我强烈建议先用UML类图把继承关系画出来。很多程序员觉得画图浪费时间，但面对复杂的继承体系，一张图能让你在5分钟内发现设计的问题，比如继承层级过深、父类方法职责不明确、子类重复定义了父类已有字段。

画UML类图常用的工具是StarUML，这是一个免费开源的建模工具，支持UML标准类图。另外，如果你用的是IntelliJ IDEA，它有内置的类图生成功能，操作路径是：右键点击一个类，选择 Diagrams -> Show Diagram Popup，就可以看到该类的继承关系图。这个功能在阅读陌生项目代码时尤其好用，一眼就能看出各个类之间的父子关系和依赖关系。

UML类图中，继承关系用一条带空心箭头的实线表示，箭头指向父类。这个箭头含义必须记清楚：空心箭头是继承，实线是关联，虚线是依赖，空心菱形是聚合，实心菱形是组合。很多人画图时把继承画成实线箭头，这就是完全理解反了。

还是拿宝可梦的例子来说。类图画出来应该是：最顶层是Pokemon抽象类，下面三个分叉箭头分别指向Pikachu和Charmander，如果需要Bulbasaur就在箭头上面多加一条线。如果还有其他非继承的关系，比如BattleManager管理战斗双方，这是一种"依赖"关系，用虚箭头从BattleManager指向Pokemon。

画完类图，你会立刻注意一个问题：如果每个子类的useSkill都是独特实现，父类的抽象方法就完全合理，不会有冗余。但如果子类之间出现了大段重复代码，比如Pikachu和Raichu（皮卡丘的进化形态）的技能逻辑高度相似，你就应该考虑之间再插一层中间类，或者用模板方法模式把公共流程提到父类。

3.3 特殊场景：多继承、抽象类与接口的取舍

说到继承，就不能不提抽象类和接口。我看到网上关于"抽象类和普通类的区别"的问题很多，这里用最直白的方式说清楚。

普通类可以实例化，抽象类不能实例化。为什么不能实例化？因为抽象类里定义了一个或多个没有方法体的抽象方法，这些方法等待子类来完整实现。一个没有完整实现方法的类，如果允许实例化，调用者调用到那个方法就会不知所措。Java的解决思路很简单，就是不让你new它。

接口和抽象类的区别，很多书上都列了对比表，但真正理解起来只需要抓住一点：抽象类是"部分实现"，接口是"纯约定"。抽象类可以有字段、有构造方法、有已经实现好的公共方法，也可以有抽象方法；接口在Java 8之前只能有方法声明和常量，Java 8之后可以加默认方法，但仍然不能有实例字段。

在继承设计里，我的经验法则是：如果你有多个类共享了大量可复用的实现代码，用抽象类；如果你只是想约定多个类必须实现某些方法，用接口。一个典型的组合是：抽象类实现接口，把公共代码留在抽象类里，子类只实现各自差异的部分。

Java自身很经典的一个例子就是AbstractList。List是接口，约定了一组方法；AbstractList是抽象类，把add、remove等方法的公共逻辑实现了一大半，ArrayList和LinkedList只需要各自实现底层存储相关的少数方法。这个设计既保证了接口的统一约束，又把复用做到了极致。

Python的多继承虽然灵活，但也不是想怎么继承就怎么继承。多继承最著名的坑叫"菱形问题"（钻石问题）：D同时继承B和C，而B和C都继承自A，那么D调用一个从A继承的方法，到底走B还是C的版本？Python用__mro__（方法解析顺序）解决了这个问题，大体规则是"深度优先，保持单调"。而Java直接拒绝了这个麻烦，只允许单继承类，多继承用接口实现，接口之间也可以继承。接口之间可以多继承，但接口没有方法实现，也就不存在菱形问题带来的方法冲突。

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

4.1 编译报"找不到类"的真正原因

我在日常开发中被问过最多的问题，就是"明明代码都在，为什么编译报找不到类"。这类问题新手遇到非常抓狂，但其实排查思路很固定，按顺序来基本都能解决。

最常见的几个原因：

• 类路径（classpath）没配好。代码文件存在，但编译器或运行时没有把它所在的目录、JAR包加到类路径里。用命令行写Java程序时，javac和java的-cp参数是很多人经常漏掉的。用IDEA等IDE开发时，依赖没被正确引入也属于这一类。
• Maven或Gradle依赖没刷新。在pom.xml里添加了依赖，但没有重新导入，IDE里的类库索引还是旧的。这个问题的解决方案通常是点一下"Maven Reload Project"按钮。
• 模块信息（module-info.java）导致的模块不可见问题。Java 9引入了模块系统，如果模块没有exports对应的包，其他模块就访问不到里面的类。这类问题在普通开发中不常见，但在多模块项目里经常折腾人。
• 包名与目录不一致。Java要求类的包名必须与文件路径对应，放错了目录，编译器找不到类是必然的。

我实际遇到过一个特别值得分享的例子：同事用Maven编译项目，报错找不到com.sun.image.codec.jpeg.JPEGCodec。代码里确实引用了这个类，IDE里也搜得到，但编译就是过不去。原因是什么？com.sun开头的包是JDK内部API，Java 9之后默认不允许访问，需要额外加--add-exports参数才能编译。这类内部API引用在旧项目里非常常见，尤其是涉及图片处理的代码。解决方案有两个：一是升级替换成非JDK内部API（比如用ImageIO），二是临时加编译参数放行。我强烈建议选方案一，因为内部API在后续JDK版本中随时可能被移除，现在能编译不代表两个月后还能编译。

另一个高频问题是在Eclipse里报"找不到或无法加载主类 org.apache.catalina.startup.Bootstrap"，这个一般是Tomcat插件或运行配置出了问题。排查思路是先确认Tomcat的运行时环境是否配置正确、server runtime是否关联。顺带提一句，现在新项目大多数用Spring Boot内嵌Tomcat或者直接用IDEA跑，遇到传统Eclipse Tomcat问题的人已经越来越少了。

4.2 匿名内部类、Lambda与继承的关联

继承和内部类看起来很独立，但在Java实际开发里经常碰面。

匿名内部类本质上是"没有显式类名"的局部类，它可以继承某个父类或者实现某个接口。典型的使用场景是一次性定制某个对象的行为。比如：

Pokemon specialPokemon = new Pokemon("神秘角色", 999, 99, 50) { @Override public void useSkill(Pokemon target) { // 特殊定制技能 target.hp = 0; } };

这段代码创建了一个继承自Pokemon的匿名子类实例，重写了useSkill方法。匿名内部类能访问外部方法里的局部变量，但如果局部变量在内部类里被读取，这个变量必须是final或"effectively final"的。Java 8之前必须显式加final关键字，Java 8之后放宽为值不变就行。这个限制的原因是生命周期问题——局部变量在栈上，内部类对象可能存活更久，Java通过把变量值复制一份到内部类对象里来保证安全，如果允许变量后续被修改，复制过来的旧值和新值不一致，就会引发逻辑混乱。

Java 8之后Lambda表达式大量出现，匿名内部类的使用频率下降了不少。Java里"lambda调用内部类示例"是一个常见的并发编程技巧——在Lambda表达式中调用外部对象的内部类方法。但这个模式容易踩一个坑：Lambda捕获外部类实例时，会持有该实例的隐式引用，如果这个引用本该被GC回收却因为Lambda存在而被长期持有，就会导致内存泄漏。这个问题的经典案例就是用Lambda在静态线程池里执行任务，结果Lambda里绑定了某个Activity/Fragment对象，对象释放不掉了。

比较新的技术方案是把回调转换成挂起函数。Android开发中经常听到"kotlin回调转挂起工具类"，本质上是用suspendCancellableCoroutine把传统的回调API包装成一个可挂起的函数，避免回调地狱。这个思想在纯Java里也可以用CompletableFuture实现，原理是一样的——把异步回调包装成统一的结果对象。

4.3 析构顺序与资源释放的坑

父类子类的析构函数执行顺序是个经典考题。Java的析构概念已经淡化了，finalize()从Java 9开始被标记过时，基本上不推荐使用，所以Java这边的答案意义不大。但C++或者Python项目中这个问题非常重要。

C++中，析构顺序和构造顺序完全相反：先构造父类，先执行子类析构，再执行父类析构。原因是编译器保证"子类部分"的内存先释放，再释放"父类部分"。这个顺序是严格约定的，如果你手动写代码模拟"从父到子"的析构顺序，很容易造成子类使用的父类资源已经被释放掉的问题。

Python中的__del__方法也是类似规则，不过Python是垃圾回收语言，__del__的触发时机不可预测，依赖它来做资源清理不是一个好主意。Python官方推荐的资源清理方案是用with语句配合上下文管理器，而不是依赖析构函数。在继承体系中，如果一个父类定义了__del__，子类也定义了__del__，子类的__del__不会自动调用父类的__del__，必须手动调用super().__del__()，漏掉的话父类的清理逻辑不会执行。这种坑在Python项目里遇到过不止一次。

Java在资源释放上使用的是try-with-resources语法，这个机制在继承场景下也需要注意。如果父类实现了Closeable接口，子类继承了它，那么子类如果自己持有额外的资源，就必须在子类的close()中先释放自己的资源，再调用父类的close()。顺序和析构一样，先子后父。很多人写close()时直接盖掉父类的实现而不调用super.close()，导致父类持有的资源泄漏。

4.4 找不到方法的运行时错误

如果说编译期的"找不到类"还算排查容易，那运行期的"找不到方法"就更隐蔽，也更考验技术。这类问题的根源通常是接口或父类的方法不存在、包冲突导致加载了旧版本的类库。

我处理过一个典型的案例：项目引入了两个第三方JAR，这两个JAR里各自打包了同一个类但版本不一致，运行时类加载器按顺序找到了旧的那个版本，结果新版本才有的方法在旧版本里不存在，一调用就抛NoSuchMethodError。排查方法是用Maven的dependency:tree插件检查是否有重复依赖，然后用exclusion把旧的排除掉。

另一个常见场景是JDK版本升级导致的类库不兼容。旧项目从Java 8升到Java 11或17，如果用了反射代码或者RMI这类依赖内部实现的框架，经常会遇到ClassNotFoundException或NoClassDefFoundError。核心原因是Java模块系统把这个包从默认可见性里移除了。遇到这类问题，要先去看报错信息里是哪个类找不到，再判断这个类属于哪个模块，最后决定加什么JVM参数或者换掉这个用法。

4.5 Maven编译找不到类的几个特殊场景

Maven项目的"找不到类"问题，比普通Java项目更容易出，因为Maven的编译生命周期和IDE的缓存机制存在一些差异。下面几个场景我在开发中都见过，值得单独列出来：

• mvn compile能通过但mvn test报找不到测试类。原因是测试代码没有放在src/test/java目录下，或者测试类文件名与类名不一致。
• 打包时找不到本地JAR中的类。项目中引用了通过system scope引入的本地JAR，Maven打包时默认不会把system scope的依赖带进来，需要在插件里额外配置。现在这个做法不推荐了，建议把本地JAR安装到本地仓库或者使用maven-install-plugin处理。
• 子模块找不到父模块的类。在多模块项目中，子模块的pom.xml里忘记加<parent>依赖，或者父模块没有先执行mvn install安装到本地仓库，子模块编译自然找不到父模块的类。
• IDE能编译但命令行Maven报找不到类。这种一般是IDE的编译输出目录和Maven的target/classes不完全同步。多次mvn clean后再编译一次，基本能解决。

Eclipse项目还有个老旧但常见的错误是"找不到或无法加载主类 org.apache.catalina.startup.Bootstrap"。这个错误几乎都与Eclipse内置Tomcat的运行时环境有关，典型的排查步骤是右键项目 -> Build Path -> Add Library -> Server Runtime -> 选择对应Tomcat版本。项目如果换了机器或者Tomcat路径变了，记得检查这个配置。

5. 继承体系设计的一些个人经验

这篇文章写到现在，核心内容基本覆盖了。最后分享几条我在实际工作中攒下来的体会。

第一，继承的深度尽量控制在三层以内。我在代码评审时看到继承层级超过四层的，第一反应就是建议重构。层数每加一层，你理解代码时就得在前缀多绕一圈，排错时也要多翻一层。这个成本不是线性增长的，是几何级数增长的。

第二，父类里尽量多用模板方法模式。把流程框架写到父类，把可变步骤抽象成方法由子类实现。这样做的好处是，业务主流程只维护一份，不会因为各个子类各自写了一套流程导致流程漂移。我在支付模块重构时用过一次这个模式，原来四五个渠道各自写了一遍流程，重构后统一父类模板方法，渠道差异压缩到只有几个钩子方法。

第三，优先用组合而不是继承。这句话是Effective Java里最经典的建议之一，但很多人只记住了"组合优于继承"这句话，不知道什么时候用。我的体会是：如果你只需要复用某个类的实现，但逻辑上两个类构不成"is-a"关系，就用组合——在类里放一个字段来持有那个类的实例。比如"电脑"和"CPU"之间就是组合关系，你不会让电脑去继承CPU，而是在电脑类里持有一个CPU对象。继承是把任何能复用就往上挂的思维，在新手代码里特别常见，这种代码最需要重构。

第四，画图不丢人，代码看不懂才丢人。在动手写继承代码前，先画UML类图确认关系，这是很多大厂做系统设计时的标准动作。IDEA里自动生成类图看一下，再回来看代码，大部分"怎么绕都绕不出来"的问题都能迎刃而解。

继承这个东西，说起来就是Object-Oriented的三大基石之一，但用得好与用得烂，写出来的代码天差地别。我用宝可梦游戏的案例串了整篇文章，因为游戏角色的继承关系是最直观的——你想想"属性相克"这种需求，如果没有继承和多态，代码会变成什么样。这本身就是很好的自我检验方式：如果你能设计出一套让新增角色只需新增一个类、不动一行已有逻辑的设计，那你对继承的理解就基本过关了。