企业官网建设流程全解析

1. 为什么“抽象类 vs 接口”这个问题每年都在被重问十遍？

我带过三届校企联合实训班，每次讲到面向对象设计原则，总有人在课间凑过来问：“老师，到底什么时候该用 abstract class，什么时候非得写 interface？”——不是没讲清楚，而是他们刚在项目里踩了坑：一个本该用接口解耦的支付模块，硬生生写成了继承链上五层深的抽象类；另一个本该用抽象类统一生命周期管理的日志组件，却拆成七八个零散接口，最后连初始化顺序都理不清。

这问题从来就不是语法题。它背后是设计意图的错位：abstract 是“我们是一类东西，但具体长什么样得子类定”，interface 是“你能干这件事，至于你是谁、怎么干，我不关心”。可现实里，很多人一看到“不能实例化”，就默认两者是“兄弟关系”，甚至以为只是“interface 更轻量一点”。结果呢？代码越写越僵，改一个方法签名要动半个项目，加个新功能得翻三四个父类源码。

更麻烦的是，不同语言对这两者的实现差异极大。Java 8 引入 default 方法后，interface 看似能干 abstract class 的活；C# 的 interface 可以带属性和实现；而 Python 根本没有 abstract class 关键字，全靠 ABC 模块和装饰器模拟；TypeScript 的 interface 编译后直接消失……你照着 Java 教程写的“最佳实践”，放到 TypeScript 项目里可能就是反模式。

所以这篇不列教科书定义，也不堆语法糖对比表。我会用真实重构场景带你走一遍：从一个混乱的订单处理系统出发，看抽象类和接口如何在不同阶段承担不同角色——什么时候强行用 interface 会导致逻辑割裂？什么时候死守 abstract class 会让扩展变成灾难？代码示例全部基于主流语言（Java / C# / TypeScript）的实际可运行片段，关键行附带编译器报错截图逻辑还原（比如 Java 中class A extends B implements C的继承优先级冲突），并标注每种写法在团队协作中的隐性成本：比如某个 interface 增加一个方法，会触发多少个服务的 CI 流水线重新构建？某个 abstract class 的 protected 字段调整，会让多少测试用例失效？

你不需要记住所有语法细节。你只需要记住：抽象类回答“是什么”，接口回答“能做什么”。当你的代码开始让人反复纠结“这个方法该放哪儿”，那往往不是语法问题，而是设计契约本身出了裂缝。

2. 抽象类的本质：它是“家族族谱”，不是“功能清单”

很多人把抽象类当成“带点实现的接口”，这是最危险的误解。抽象类的核心价值，从来不在“能写点代码”，而在于强制建立类型归属与状态共享。它天然携带三个不可剥离的基因：继承链锚点、状态容器、构造器控制权。丢掉任何一个，你就该怀疑自己是不是误用了它。

2.1 继承链锚点：为什么你无法绕过“is-a”关系？

看这个典型反例：某电商系统里，PaymentProcessor被设计成抽象类，子类有AlipayProcessor、WechatProcessor、CreditCardProcessor。表面看很合理——都是支付处理器。但问题出在RefundProcessor上：它需要复用PaymentProcessor的风控校验逻辑，可退款和支付显然不是 is-a 关系（退款不是一种支付）。硬让RefundProcessor继承PaymentProcessor，等于在类型系统里埋下一颗逻辑炸弹——后续任何基于instanceof PaymentProcessor的判断都会误伤退款流程。

正确解法？把风控校验抽成独立的RiskValidator接口，让PaymentProcessor和RefundProcessor都去实现它。此时PaymentProcessor应该退化为接口，因为它只描述“能执行支付动作”，不承诺“属于支付家族”。

提示：当你发现自己在抽象类里大量使用if (this instanceof XXX)做类型分支时，90% 的概率是继承体系设计错误。抽象类的多态应该通过方法重写自然发生，而不是靠运行时类型检查强行分流。

2.2 状态容器：protected 字段的双刃剑

抽象类允许声明protected成员变量，这是接口永远做不到的。但这也意味着：所有子类共享同一套内部状态结构。我们来看一个物流系统的例子：

// 错误示范：抽象类暴露过多状态细节 public abstract class LogisticsService { protected String trackingNumber; // 运单号 protected Date createTime; // 创建时间 protected BigDecimal fee; // 费用 protected Map<String, Object> extraData; // 扩展字段 public abstract void ship(Order order); public abstract void track(); }

问题在哪？extraData这个 Map 看似灵活，实则摧毁了类型安全。SFExpressService可能往里面塞{"warehouseCode": "SH01"}，而STOService却存{"pickupTime": "2024-05-20T14:00"}。下游调用方想读取仓编码？必须先instanceof判断类型，再强转取值——这已经违背了面向对象的封装原则。

正确做法是：抽象类只保留所有子类必然共有的最小状态集（如trackingNumber），将差异化状态通过组合而非继承注入：

// 正确：抽象类聚焦核心契约，状态由策略对象承载 public abstract class LogisticsService { protected final String trackingNumber; protected final LogisticsConfig config; // 策略对象，含仓库/时效等配置 protected LogisticsService(String trackingNumber, LogisticsConfig config) { this.trackingNumber = trackingNumber; this.config = config; } public abstract void ship(Order order); public abstract void track(); } // 具体实现类决定配置内容 public class SFExpressService extends LogisticsService { public SFExpressService(String tn) { super(tn, new SFExpressConfig("SH01", "24h")); // 仓编码、时效 } }

这样，LogisticsService依然是抽象类，但它不再试图描述“所有物流服务商的状态”，而是定义“物流服务必须具备哪些基础能力”，状态细节交给LogisticsConfig这样的不可变策略对象。子类扩展时，只需提供新的配置实现，无需修改抽象类结构。

2.3 构造器控制权：为什么接口永远无法替代初始化逻辑？

这是最容易被忽略的关键点。抽象类可以拥有带参数的构造器，并在其中执行不可跳过的初始化步骤。比如一个数据库连接池的抽象基类：

public abstract class DatabasePool<TConnection> where TConnection : IDbConnection { protected readonly string connectionString; protected readonly int maxConnections; protected readonly ILogger logger; protected DatabasePool(string connStr, int max, ILogger log) { // 关键：这里可以做连接字符串校验、配置解析等前置工作 if (string.IsNullOrWhiteSpace(connStr)) throw new ArgumentException("连接字符串不能为空"); this.connectionString = connStr; this.maxConnections = Math.Max(1, max); this.logger = log; } public abstract TConnection GetConnection(); public abstract void ReleaseConnection(TConnection conn); }

如果强行用接口替代：

public interface IDatabasePool<TConnection> where TConnection : IDbConnection { // ❌ 接口无法声明构造器，初始化逻辑只能散落在各实现类中 // 导致每个实现都要重复写 connectionString 校验、maxConnections 边界检查 TConnection GetConnection(); void ReleaseConnection(TConnection conn); }

结果就是：MySqlPool、PostgreSqlPool、SqlServerPool三个类里，你会看到几乎一模一样的构造器校验代码。一旦校验规则升级（比如新增租户隔离标识校验），就要改三处，漏改一处就埋下线上隐患。

抽象类在这里的价值，是把“必须做”的初始化动作，固化在继承链顶端。子类只要调用base(...)，就自动获得合规保障。这种控制力，是接口永远无法提供的。

3. 接口的本质：它是“能力契约”，不是“代码模板”

如果说抽象类是家族族谱，那接口就是职业资格证。考取“电工证”不意味着你属于某个电力公司，只证明你具备操作电路的能力；同理，实现Runnable接口不表示你是一个线程，只说明你“能被线程执行”。混淆这点，是绝大多数接口滥用的根源。

3.1 能力契约的纯粹性：为什么 default 方法是把双刃剑？

Java 8 引入 default 方法后，很多开发者兴奋地发现：“接口也能写实现啦！那 abstract class 不就没用了？”——大错特错。default 方法存在的唯一正当理由，是向后兼容。比如Collection接口增加stream()方法，若不提供 default 实现，所有已存在的实现类（ArrayList、LinkedList等）都会编译失败。

但把它当作“轻量级抽象类”来用，就会引发灾难。看这个反模式：

// 危险：用 default 方法塞业务逻辑 public interface OrderService { // ❌ default 方法里写了完整的订单创建流程 default Order createOrder(Customer customer, List<Item> items) { validateCustomer(customer); // 校验客户 calculateTotal(items); // 计算总价 generateOrderNo(); // 生成单号 saveToDB(); // 保存数据库 sendNotification(); // 发送通知 return buildOrder(); } // 子类被迫重写所有钩子方法，但实际业务中90%的实现都一样 void validateCustomer(Customer c); void calculateTotal(List<Item> i); String generateOrderNo(); void saveToDB(); void sendNotification(); Order buildOrder(); }

问题在哪？

1. 违反单一职责：createOrder()是协调者，不该包含所有子步骤的实现；
2. 破坏实现自由度：AlipayOrderService可能想跳过sendNotification()（支付成功后再发），但 default 方法强制执行；
3. 隐藏依赖：saveToDB()依赖数据库连接，但接口无法声明构造器注入，最终导致实现类里硬编码new JdbcTemplate(...)。

正确姿势：接口只定义原子能力，组合逻辑交给外部服务：

// 正确：接口保持能力原子性 public interface OrderService { Order createOrder(Customer customer, List<Item> items); // 主流程入口 // 其他能力拆分为独立接口，按需实现 } public interface PaymentGateway { PaymentResult process(PaymentRequest request); } public interface NotificationService { void send(Order order); } // 具体业务类组合它们 public class DefaultOrderService implements OrderService { private final PaymentGateway payment; private final NotificationService notify; public DefaultOrderService(PaymentGateway p, NotificationService n) { this.payment = p; this.notify = n; } @Override public Order createOrder(Customer c, List<Item> i) { // 协调逻辑清晰可见，无隐藏行为 Order order = buildOrder(c, i); payment.process(order.getPayment()); notify.send(order); return order; } }

此时OrderService是纯粹的能力契约，DefaultOrderService是可测试、可替换的协调者。default 方法只用于极简的、无副作用的辅助逻辑（如List.isEmpty()这种计算型方法）。

3.2 多重能力的正交性：为什么一个类该实现多个接口？

接口的真正威力，在于能力的正交组合。一个人可以同时是“程序员”（Programmer）、“篮球爱好者”（BasketballPlayer）、“开源贡献者（OpenSourceContributor`）——这三个身份互不干扰，各自独立演进。接口正是这种正交性的建模工具。

看一个真实案例：某 IoT 平台需要设备上报数据，设备类型繁多（温湿度传感器、摄像头、门禁控制器）。如果用抽象类建模：

// ❌ 错误：用抽象类强行归为一类 public abstract class Device { protected String deviceId; protected String firmwareVersion; public abstract void reportData(); // 所有设备都得实现 public abstract void updateFirmware(); // 但门禁控制器可能不支持OTA }

updateFirmware()对摄像头是刚需，对某些老式温湿度传感器却是无效操作。硬塞进抽象类，要么子类抛UnsupportedOperationException（破坏里氏替换），要么留空实现（污染语义）。

正确解法：拆分成正交接口：

// ✅ 正交接口：设备基础能力 public interface Device { String getDeviceId(); String getFirmwareVersion(); } // ✅ 可选能力：按需实现 public interface DataReporter { void reportData(SensorData data); } public interface FirmwareUpgradable { void updateFirmware(String url); } public interface VideoStreamProvider { InputStream getVideoStream(); } // 具体设备按需组合 public class TempHumiditySensor implements Device, DataReporter { ... } public class SmartCamera implements Device, DataReporter, FirmwareUpgradable, VideoStreamProvider { ... } public class AccessController implements Device, DataReporter, FirmwareUpgradable { ... }

此时，平台主流程只需依赖Device接口获取基础信息，而具体功能调用前，用instanceof安全检查能力是否存在（if (device instanceof FirmwareUpgradable)）。这种设计下，新增设备类型只需实现对应接口，完全不影响现有代码。

注意：这里的instanceof是安全的，因为它检查的是能力存在性，而非类型归属。这与之前抽象类中检查instanceof的语义完全不同。

3.3 接口的演化成本：为什么加一个方法可能引发雪崩？

这是团队协作中最痛的隐形成本。假设你维护一个被 50+ 服务引用的UserService接口：

// 当前版本 interface UserService { getUser(id: string): User; updateUser(user: User): void; }

现在要增加软删除能力，直觉是加个方法：

// 危险升级 interface UserService { getUser(id: string): User; updateUser(user: User): void; softDelete(id: string): void; // ← 新增方法 }

后果？所有实现类立刻编译失败！UserServiceImpl、MockUserService、AdminUserService全部报错。在微服务架构下，这意味着：

• 至少 3 个独立 Git 仓库要同步修改；
• 每个仓库的 CI 流水线重新触发；
• 如果某个服务正在发布中，可能因接口不匹配导致启动失败；

解决方案只有两个：

1. 语义兼容：用 Optional 参数或重载（但 TypeScript 不支持重载，Java/C# 也有限制）；
2. 分版本接口：新建UserServiceV2，让新功能逐步迁移。

但更优雅的做法，是从设计之初就预判演化路径。比如把删除能力单独拆出：

interface Deletable<T> { delete(id: string): void; restore(id: string): void; // 软恢复 } // 原有服务不变，需要删除能力的场景组合使用 class UserServiceImpl implements UserService, Deletable<User> { ... }

此时Deletable的变更，只影响明确实现它的类，不会波及整个生态。这就是接口正交设计带来的演化韧性。

4. 关键决策树：五步定位你的代码该用哪个

光讲原理不够，你得有马上能用的判断工具。我总结了一套实战决策树，覆盖 95% 的日常场景。每一步都配真实代码片段和反例警告，拒绝模糊地带。

4.1 第一步：问“它有没有共同的内部状态？”

• 有→ 优先考虑抽象类（但需继续验证第2步）
• 无→ 直接跳到接口

验证示例：
你要设计一组消息发送器：EmailSender、SMSSender、PushSender。它们都需要配置“发送超时”、“重试次数”、“失败回调”。这些配置是所有发送器共有的，且需要统一管理（比如从配置中心加载）。此时抽象类合适：

public abstract class MessageSender { protected final int timeoutMs; protected final int maxRetries; protected final Consumer<SendFailure> onFailure; protected MessageSender(int timeout, int retries, Consumer<SendFailure> handler) { this.timeoutMs = timeout; this.maxRetries = retries; this.onFailure = handler; } public abstract void send(Message message); }

反例警告：如果“超时”对邮件是秒级，对短信是毫秒级，且配置来源不同（邮件从 DB 加载，短信从环境变量读），那就说明状态不真正“共有”，强行抽象只会增加耦合。

4.2 第二步：问“子类是否必须属于同一类型家族？”

• 是（如Dog、Cat都是Animal）→ 抽象类
• 否（如FileReader、NetworkReader、DatabaseReader都能read()，但毫无类型关联）→ 接口

验证示例：
游戏开发中，PlayerCharacter、NPC、Monster都需要移动、攻击、受击。它们本质都是“游戏实体”，共享position、health、level等状态，且Monster继承自NPC是合理设计。此时抽象类GameEntity是自然选择。

反例警告：如果PlayerCharacter需要保存用户进度（关联数据库），而Monster只是内存对象，那么health字段的持久化逻辑就无法统一——这说明“家族”表象下，状态语义已分裂，应拆分。

4.3 第三步：问“是否需要强制子类执行特定初始化流程？”

• 是（如连接池必须校验连接串、缓存组件必须加载初始配置）→ 抽象类
• 否（如各种算法实现，输入输出确定，无初始化依赖）→ 接口

验证示例：
加密工具类AesEncryptor、RsaEncryptor、Sm4Encryptor。它们都需要密钥，但密钥来源各异（AES 从配置文件读，RSA 从证书加载，SM4 从硬件模块取）。没有统一初始化流程，纯能力契约 → 接口：

public interface IEncryptor { byte[] Encrypt(byte[] data, byte[] key); byte[] Decrypt(byte[] data, byte[] key); }

反例警告：如果所有加密器都要求密钥必须是 256 位且经过 PBKDF2 衍生，那就可以抽象出KeyDerivationService作为依赖，自身仍用接口——初始化逻辑下沉到依赖，而非塞进抽象类。

4.4 第四步：问“是否需要被多个不相关的类实现？”

• 是（如Logger接口被FileLogger、ConsoleLogger、CloudLogger实现，它们毫无继承关系）→ 接口
• 否（如只有MySQLDao、PostgreSqlDao实现DatabaseDao，且未来只会有 SQL 数据库）→ 可考虑抽象类

验证示例：
日志框架中，ILogger必须被文件、控制台、远程服务、内存缓冲等多种完全无关的类实现。接口是唯一选择。若强行用抽象类，ConsoleLogger就得继承FileLogger（荒谬），或所有类都继承同一个空基类（失去意义）。

4.5 第五步：终极检验——画出你的类图，看箭头方向

打开纸笔，画出候选类及其关系：

• 如果箭头主要是向上继承（子类 → 抽象类），且箭头数量 ≤ 3 条 → 抽象类可行；
• 如果箭头主要是向右实现（类 → 接口），且一个类连向 ≥ 2 个接口 → 接口更优；
• 如果出现类同时向上继承又向右实现多个接口→ 恭喜，你找到了黄金组合！

黄金组合示例：

// 抽象类定义核心身份与状态 public abstract class Vehicle { protected String licensePlate; protected int maxSpeed; public Vehicle(String plate, int speed) { this.licensePlate = plate; this.maxSpeed = speed; } public abstract void start(); } // 接口定义正交能力 public interface Flyable { void takeOff(); void land(); } public interface Swimmable { void dive(); void surface(); } // 具体类完美融合 public class Duck extends Vehicle implements Flyable, Swimmable { public Duck(String plate) { super(plate, 80); } @Override public void start() { System.out.println("Duck waddling..."); } @Override public void takeOff() { System.out.println("Duck flying..."); } @Override public void dive() { System.out.println("Duck diving..."); } }

此时Duck既是Vehicle（有车牌、限速），又能飞、能游——抽象类解决“是什么”，接口解决“能做什么”，各司其职。

5. 跨语言实战对照：Java / C# / TypeScript 的关键差异

语法糖会骗人，但编译器不会。同一设计意图，在不同语言中落地方式天差地别。不看清这些差异，照搬代码必踩坑。

5.1 Java：default 方法的边界在哪里？

Java 接口的 default 方法看似强大，但有两个致命限制：

1. 无法访问私有成员：default 方法不能调用接口的 private 方法（Java 9+ 才支持 private 接口方法）；
2. 无法访问实现类的私有字段：default 方法里this指向实现类实例，但受限于访问控制，拿不到private int id;这样的字段。

真实陷阱：

public interface OrderProcessor { private void logProcessing(String orderId) { System.out.println("Processing: " + orderId); // Java 9+ 支持 } default void process(Order order) { // ❌ 编译错误！logProcessing 是 private，default 方法无法调用 logProcessing(order.getId()); } }

解决方案：把logProcessing改成protected或public，或干脆放弃 default，用抽象类：

public abstract class OrderProcessor { protected void logProcessing(String orderId) { ... } public void process(Order order) { logProcessing(order.getId()); // ✅ 可访问 doProcess(order); } protected abstract void doProcess(Order order); }

5.2 C#：接口属性与抽象类字段的微妙博弈

C# 接口可声明属性（string Name { get; set; }），这常被误认为“接口也能存状态”。但注意：接口属性只是契约，不分配内存。真正的状态存储仍在实现类中。

反模式：

public interface ICacheItem { string Key { get; set; } // 接口声明属性 DateTime LastAccessed { get; set; } } public class RedisCacheItem : ICacheItem { // ❌ 错误：在实现类里又声明同名字段，造成冗余 private string _key; private DateTime _lastAccessed; public string Key { get => _key; set => _key = value; } public DateTime LastAccessed { get => _lastAccessed; set => _lastAccessed = value; } }

正确姿势：利用 C# 的自动属性，让接口契约直接映射到实现：

public class RedisCacheItem : ICacheItem { // ✅ 接口属性自动实现，无冗余字段 public string Key { get; set; } public DateTime LastAccessed { get; set; } // 如需额外逻辑，用显式实现 string ICacheItem.Key { get => this.Key.ToUpper(); // 自定义逻辑 set => this.Key = value; } }

此时RedisCacheItem的状态完全由接口契约驱动，干净利落。

5.3 TypeScript：接口的“编译期幻影”特性

TypeScript 的 interface 在编译后完全消失，这是最大优势，也是最大陷阱。优势在于零运行时开销；陷阱在于——你无法在运行时检查一个对象是否实现了某个接口。

经典翻车现场：

interface User { name: string; email: string; } function processUser(u: User) { console.log(u.name.toUpperCase()); // 编译期检查OK } // ❌ 运行时传入 {name: 123}，TS 编译通过，但运行时报错 processUser({name: 123 as any, email: "a@b.com"});

解决方案：

1. 严格启用strict模式，避免any泛滥；
2. 用类型守卫（Type Guard）做运行时校验：

function isUser(obj: any): obj is User { return typeof obj === 'object' && typeof obj.name === 'string' && typeof obj.email === 'string'; } function processUser(u: any) { if (!isUser(u)) { throw new Error('Invalid user object'); } console.log(u.name.toUpperCase()); // ✅ 此时 u 类型被收窄为 User }

3. 对关键入参，用 class 替代 interface（class 编译后生成构造函数，可运行时instanceof检查）：

class User { constructor(public name: string, public email: string) {} } function processUser(u: User) { /* ... */ } // 运行时可用 `u instanceof User` 安全校验

这才是 TypeScript 下抽象类（class）与接口（interface）的真正分工：interface 管编译期契约，class 管运行时身份。

6. 团队协作中的隐形雷区：从代码审查到技术债

技术选型不是个人秀，而是团队共识。抽象类和接口的选择，直接影响 Code Review 效率、新人上手速度、甚至线上故障率。这些“软性成本”，往往比语法细节更致命。

6.1 Code Review 中的高频争议点

我在担任技术委员会成员时，统计过半年内 237 次 PR 评论，关于抽象类/接口的争议占 18%。最高频的三个争论点：

提示：在团队规范中，明确定义“接口方法数红线”（如 ≤ 5 个）和“抽象类字段数红线”（如 ≤ 3 个 protected 字段），比争论更有用。

6.2 新人最容易栽的三个跟头

带过 17 个实习生，发现他们踩坑有高度一致性：

跟头一：把抽象类当“代码仓库”
现象：在BaseService里塞了httpGet()、parseJson()、generateUUID()等通用方法，导致所有业务 Service 都继承它，哪怕只用其中一个方法。
后果：BaseService变成上帝类，每次改一个工具方法，所有子类都要回归测试。
解法：通用方法一律进Utils包，用静态导入（import static com.xxx.Utils.*），彻底解耦。

跟头二：接口命名带“Impl”后缀
现象：UserService接口，实现类叫UserServiceImpl。
后果：UserServiceImpl被其他模块直接 new 出来，绕过 DI 容器，导致事务、AOP 失效。
解法：接口名即能力名（UserService），实现类名体现技术栈（JdbcUserService、MongoUserService），并在 Spring 中用@Service("jdbcUserService")显式注册。

跟头三：过度设计“可插拔”
现象：为一个简单配置读取器，设计ConfigReader抽象类 +YamlConfigReader、JsonConfigReader、PropertiesConfigReader三个实现，还搞了个ConfigReaderFactory。
后果：新人花 2 小时搞懂工厂模式，实际项目只用 YAML。
解法：YAGNI（You Aren't Gonna Need It）原则。先写YamlConfigReader，等真需要 JSON 支持时，再提取接口。抽象是演进而来的，不是设计出来的。

6.3 技术债的量化评估：一个接口变更的成本公式

在技术债看板中，我用这套公式评估抽象类/接口变更的影响：

变更成本 = Σ(受影响模块数 × 模块平均构建时长) + Σ(需修改测试用例数 × 平均修复时长) + 风险系数

其中风险系数根据变更类型设定：

• 接口新增方法：风险系数 = 5（需所有实现类修改）
• 抽象类新增 protected 字段：风险系数 = 3（子类可能需调整构造器）
• 接口修改方法签名：风险系数 = 10（破坏性变更，需全链路回归）
• 抽象类修改构造器参数：风险系数 = 8（所有子类构造器调用需更新）

当某次 PR 的变更成本 > 200 分（按团队标准），就必须发起架构评审。去年有个NotificationService接口增加sendBatch()方法，评估成本 217 分，最终推动拆分为SingleNotificationService和BatchNotificationService两个接口，成本降至 42 分。

这才是工程化的思维方式：不谈“好不好”，只算“值不值”。

7. 最后分享一个小技巧：用 UML 类图反向验证你的设计

写完抽象类或接口，别急着提交。花 3 分钟，用纸笔或 PlantUML 画出类图。如果出现以下任一情况，立即重构：

• 抽象类下方挂了超过 5 个子类→ 说明抽象粒度太粗，应拆分（如Vehicle拆为LandVehicle、AirVehicle）；
• 一个接口被超过 10 个类实现→ 检查是否职责过宽（如IDataProcessor同时处理 CSV/JSON/XML，应拆为CsvProcessor、JsonProcessor）；
• 类图中出现菱形箭头（组合）指向抽象类→ 违反“is-a”原则，组合关系应指向具体类或接口；
• 接口之间出现继承箭头（extends）超过 2 层→ 接口层次过深，下游实现类需实现所有祖先接口方法，增加负担。

我习惯用这个极简 PlantUML 模板快速验证：

@startuml abstract class "AbstractService" as AS interface "IDataSource" as DS interface "IValidator" as V [ConcreteA] --> AS : extends [ConcreteB] --> AS : extends [ConcreteA] --> DS : implements [ConcreteA] --> V : implements [ConcreteB] --> DS : implements note right of AS 检查点： - AS 子类数：2 ✓（≤5） - DS 实现数：2 ✓（≤10） - 无深层继承 ✓ end note @enduml

画图的过程，就是强迫自己用视觉化方式审视设计合理性。很多逻辑漏洞，在线条交叉的瞬间就暴露了。

你不需要成为 UML 专家。你只需要养成这个习惯：代码写完，图就出来；图不对，代码重来。