企业官网建设流程全解析

刚入行那会儿，我总觉得 Java 接口是个挺虚的东西——定义一堆没有方法体的方法，再让别的类去实现，绕了一圈不还是调那些实现类的方法吗？直到有一次接手支付模块，里面散落着三个渠道的逻辑，每个调用点都在写 if-else 判断渠道类型。要加第四个渠道的时候，我改了十一个文件，还漏了一处，上线当天就报了错。那次之后我才真正明白，Java 接口与实现这套机制解决的不是语法层面的复用问题，而是把"变化"约束在一个可以整体替换的边界上。接口定义的是契约，实现交付的是能力，调用方只认契约不认人，这才是它真正的价值。

这篇内容我打算把 Java 接口从定义到实现、从语法细节到工程治理完整讲一遍。不管你是刚学完 Java 基础、被 abstract 和 interface 的区别绕晕的新手，还是写了几年业务代码、想补一补动态代理和接口幂等这些工程话题的老手，都能在里面找到能直接用的东西。我会尽量少讲空泛概念，多给能抄的代码和踩过的坑，包括默认方法的冲突处理、JDK 动态代理和 CGLIB 的分工、接口版本怎么演进才不炸线上，以及面试里那几道几乎必问的题该怎么答。

1. 接口设计的第一性问题：到底该固定什么、放开什么

1.1 从调用方视角倒推接口

很多人写接口的习惯是"先把实现想清楚，再抽个接口出来"，这个顺序其实是反的。接口是给调用方看的，所以应该从调用方的需求倒推：他要完成一件事，最少需要知道哪些信息、调用哪些动作？其余的全部藏起来。

拿 JDK 集合框架举例，List接口只承诺了"有序、可重复、能用下标访问"这几件事，至于底层是数组还是链表，调用方一概不管。ArrayList和LinkedList的实现差异巨大，一个随机访问是 O(1)，一个是 O(n)，但它们对外的契约是一致的。这就是接口的威力：它把"能做什么"和"怎么做到"彻底分开了。

接口这个词在硬件领域也天天出现。USB 定义了引脚、电压和时序，插上就能通信，至于对面插的是 U 盘、键盘还是网卡，主机完全不关心。软件接口是同一个思路，只不过"引脚"换成了方法签名，"电压"换成了参数和返回值的约定。

这里有个容易犯的错误叫"大接口"。我见过一个UserService接口，里面塞了注册、登录、改密码、查积分、发消息、导出报表二十多个方法，结果每个实现类都得实现全部方法，其中一半直接throw new UnsupportedOperationException()。这就是典型的违反接口隔离原则。正确的做法是按调用方拆：前台需要UserQueryService，后台管理需要UserAdminService，各取所需，互不牵连。

判断接口粒度是否合适，我一般用两个问题自检：第一，实现这个接口的类，是不是每个方法都用得上？第二，调用这个接口的地方，是不是每次都能用上它声明的大部分方法？两个问题只要有一个答案是"否"，就该考虑拆了。

1.2 接口和抽象类的边界到底在哪

这是初学者最容易纠结的地方，也是面试的常客。我用一句话概括：抽象类描述的是"是什么"，接口描述的是"能做什么"。狗是动物，所以继承Animal抽象类；狗会叫，所以实现Barkable接口。一只机器狗也会叫，但它不是动物，照样能实现Barkable。

从语法能力上看，两者的差异可以整理成下面这张表：

这张表里最容易被忽略的是最后一行。抽象类的核心价值在于代码复用，比如模板方法模式：AbstractExportTask把读取、转换、写出的骨架写好，只留一个doWrite()让子类实现。接口的核心价值在于解耦和替换，它不关心你能不能复用代码。

所以选型逻辑很清楚：如果你有一批类共享一段稳定的骨架逻辑，并且它们本质上是同一类事物，用抽象类；如果你只是想让一批毫无血缘关系的类具备某种可被统一调用的能力，用接口。

现实里两者经常搭配使用。比如定义Repository接口约定数据访问能力，再提供一个AbstractRepository抽象类实现掉公共的连接管理、日志、异常转换，具体实现类继承抽象类即可。这样接口负责契约稳定，抽象类负责省事，各司其职。

2. 接口定义的完整细节：语法、修饰符与版本演进

2.1 一个标准接口到底长什么样

先看一段最基础的定义，把它拆开揉碎讲：

public interface DataSyncService { // 常量：隐式 public static final String DEFAULT_CHARSET = "UTF-8"; // 抽象方法：隐式 public abstract SyncResult sync(String sourceId, SyncOptions options); // 默认方法：Java 8 引入 default boolean supports(String sourceId) { return sourceId != null && !sourceId.isEmpty(); } // 静态方法：Java 8 引入，属于接口本身 static DataSyncService noop() { return (sourceId, options) -> SyncResult.empty(); } // 私有方法：Java 9 引入，供上面的默认/静态方法复用 private void log(String msg) { System.out.println("[sync] " + msg); } // 嵌套接口，隐式 public static interface SyncOptions { int getBatchSize(); } }

几个细节值得单独说。第一，接口里的成员变量不管你写不写修饰符，编译器都会补成public static final，所以DEFAULT_CHARSET是个常量，而且可以通过DataSyncService.DEFAULT_CHARSET直接访问。很多人第一次看到接口里定义变量会懵，其实就是这个规则。

第二，接口里的方法在 Java 8 之前只能是抽象方法，隐式public。注意这里没有abstract也得是abstract，而且不能是 protected 或 private——早期版本里私有方法会直接编译报错，直到 Java 9 才放开。

第三，嵌套接口默认是static的，不需要也不能显式写static（写了反而在某些老版本编译器上报警告）。它的常见用途是把紧耦合的类型收拢在同一个命名空间下，比如Map.Entry、ApplicationContext里那一堆嵌套接口。

还有一点新手常踩的坑：接口不能被实例化，但可以声明引用。DataSyncService service = new DbSyncServiceImpl();这行代码左边是接口类型，右边是实现类，编译期检查的是接口有没有sync方法，运行期执行的是实现类的版本。这个"编译看左边、运行看右边"的规则，是理解多态和动态代理的基础，后面第 3 节会重点展开。

2.2 默认方法带来的便利与新麻烦

Java 8 引入default方法，官方说法是为了在不破坏已有实现类的前提下给接口加新方法。这个理由非常实在：Collection接口在 Java 8 里加了几十个方法，如果全是抽象方法，全世界的Collection实现类都得重写一遍，那场面没法看。

default的实际用法很简单，给个默认实现，实现类不覆盖就用接口的。但真正麻烦的是菱形继承：如果一个类实现了两个接口，而这两个接口有签名相同的默认方法，编译器会直接报错，要求你必须重写：

interface A { default String hello() { return "A"; } } interface B { default String hello() { return "B"; } } class C implements A, B { // 不重写会编译报错：继承了两个不相关的 hello() 默认实现 @Override public String hello() { return A.super.hello() + "&" + B.super.hello(); } }

A.super.hello()这个语法是调用指定接口默认实现的唯一方式，注意它只在类的实例方法里可用，静态上下文里写不了。

还有一条规则很容易记混：类优先于接口。如果一个类继承的父类里有一个具体方法，同时又实现了一个带同名默认方法的接口，那么父类的方法胜出，接口的默认实现被忽略。这条规则保证了向后兼容，但也常常让人困惑——明明接口里写了默认实现，怎么跑的是父类的？遇到这种情况先看继承链，多半是类路径上的某个父类把它遮住了。

static方法则是另一个维度：它属于接口本身，不会被子接口继承，也不能被实现类调用。DataSyncService.noop()可以调，但DbSyncServiceImpl.noop()编译不过。这个设计是有意为之，避免了静态方法在继承体系里到处乱窜造成歧义。

注意：默认方法虽然方便，但不要拿它来藏业务逻辑。它对实现类是不可见的"隐式行为"，排查问题时很容易被忽略。我见过一个项目在接口默认方法里做了脏数据过滤，结果某个实现类出问题时排查了整整一天，最后才发现是这层默认逻辑干的。默认方法只适合放真正稳定的、与业务无关的通用逻辑，比如空值判断、默认参数、日志埋点。

2.3 函数式接口与 Lambda 的配合方式

一旦接口里只剩一个抽象方法，它就成了函数式接口，可以用 Lambda 或方法引用来写。@FunctionalInterface这个注解是给编译器看的，加上之后如果你手滑写了两个抽象方法，编译期就会报错。注意它只约束抽象方法的数量，默认方法和静态方法不算。

JDK 内置的四大函数式接口值得背下来，日常写代码用得极多：

用起来是这样的：

Function<String, Integer> len = String::length; Predicate<String> notBlank = s -> s != null && !s.trim().isEmpty(); Consumer<String> printer = System.out::println; List<String> names = List.of("a", "", "bb"); names.stream() .filter(notBlank) .map(len) .forEach(System.out::println); // 输出 1 和 2

这里有个实用技巧：Supplier最大的价值是延迟执行。比如日志场景，如果日志级别是 DEBUG 才启动的昂贵计算，写成log.debug(() -> buildExpensiveMessage())就只在需要时才计算，比起先拼接字符串再判断级别，性能差别在高频路径上非常明显。

自定义函数式接口时，命名建议带上语义，比如OrderValidator、PriceCalculator，比MyFunction好读太多。另外尽量继承自标准接口，比如@FunctionalInterface interface Validator extends Predicate<Order>，这样能直接复用and、or、negate这些组合方法。

3. 实现层：类实现、策略组合与动态代理

3.1 类实现与方法调用的完整链路

一个类实现接口，核心要求是覆盖所有抽象方法，否则这个类必须声明为抽象类。方法签名必须完全一致，返回类型可以是被返回类型的子类型（协变返回），抛出的受检异常不能比接口声明的更宽。

真正值得关注的是运行期的调用链路。JVM 里有两条方法调用指令容易搞混：invokevirtual用于普通实例方法，invokeinterface用于接口方法。为什么接口调用要单独一条指令？因为类的方法分派可以通过固定偏移量的虚方法表高效完成，而接口方法需要额外的接口方法表来查找，历史上性能略差一些，不过现代 JVM 在这块做了大量优化，实际差距已经很小。

再说多态。下面这段代码是理解一切的钥匙：

public interface Notifier { void send(String msg); } public class SmsNotifier implements Notifier { @Override public void send(String msg) { System.out.println("sms: " + msg); } } Notifier n = new SmsNotifier(); n.send("hello"); // 运行期才决定调用 SmsNotifier.send

编译器看到n.send时只知道Notifier有这个方法，至于具体执行哪个类的方法，要等运行期看n实际指向什么对象。这个机制叫动态分派，是策略模式、依赖注入、AOP 全部的基础。理解它之后你就会明白，为什么很多框架只需要拿到接口类型就能做事——注入的对象可以是任意实现，框架根本不需要知道是哪一个。

还有个常见的认知误区：接口里的方法默认都是public，所以实现类重写时不能降低可见性。写成protected void send(...)会直接编译失败。同理，接口里不能定义final方法（默认方法也不行），否则实现类无法覆盖。

3.2 策略模式加工厂：把 if-else 干净地干掉

回到我开头提到的支付模块那个坑。当时的问题就是调用点直接判断渠道类型，代码长这样：

if ("wechat".equals(channel)) { // 微信支付逻辑 } else if ("alipay".equals(channel)) { // 支付宝逻辑 } else if ("unionpay".equals(channel)) { // 银联逻辑 }

加第四个渠道就要动这里，而且是所有调用点都要动。用接口重构之后，思路变成这样：

public interface PayChannel { String code(); // 渠道标识 PayResult pay(PayRequest request); // 支付能力 } @Component public class WechatPayChannel implements PayChannel { @Override public String code() { return "wechat"; } @Override public PayResult pay(PayRequest request) { // 具体调用微信的能力 return PayResult.success(); } } @Component public class PayChannelFactory { private final Map<String, PayChannel> channelMap = new HashMap<>(); // 构造注入所有实现，Spring 会自动把 List 塞进来 public PayChannelFactory(List<PayChannel> channels) { for (PayChannel c : channels) { channelMap.put(c.code(), c); } } public PayChannel get(String code) { PayChannel channel = channelMap.get(code); if (channel == null) { throw new IllegalArgumentException("unsupported channel: " + code); } return channel; } }

改动之后，调用方只剩一行factory.get(channel).pay(request)，加新渠道只需新增一个实现类，其他代码一行不动。这正好符合开闭原则：对扩展开放，对修改关闭。

这里有个我踩过的坑值得说。最初我在工厂里用@PostConstruct去注册，结果测试时手动 new 工厂，channelMap是空的，排查了半天。改成构造器注入之后，依赖关系变成了显式的，测试也简单了——直接new PayChannelFactory(List.of(new WechatPayChannel()))就能跑。能构造注入就别用字段注入，这是我在接口+工厂这套组合里最实在的一条经验。

顺带提一个性能方面的考量。这种工厂模式在渠道数量少（十几个以内）时毫无压力，HashMap查找是 O(1)。但如果实现类多到几百个，启动时全部初始化可能拖慢启动速度，这时候可以考虑懒加载：注册的是Supplier<PayChannel>而不是实例，真正用到时才创建。要不要优化，用启动耗时数据说话，别凭感觉提前优化。

3.3 动态代理：让接口在运行期被"改写"

动态代理是接口体系里最能体现威力的部分。核心思想是：在运行期动态生成一个实现了指定接口的类，把接口方法的所有调用转发到你写的处理器里，你就能在不改动业务代码的前提下插入日志、事务、重试、权限校验。

JDK 自带的实现只需要三样东西：类加载器、要实现的接口数组、一个InvocationHandler。

public class RetryHandler implements InvocationHandler { private final Object target; private final int maxRetry; public RetryHandler(Object target, int maxRetry) { this.target = target; this.maxRetry = maxRetry; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Throwable last = null; for (int i = 0; i < maxRetry; i++) { try { return method.invoke(target, args); } catch (InvocationTargetException e) { last = e.getTargetException(); } } throw last; } } // 生成代理对象 DataSyncService real = new DbSyncServiceImpl(); DataSyncService proxy = (DataSyncService) Proxy.newProxyInstance( real.getClass().getClassLoader(), new Class<?>[]{DataSyncService.class}, new RetryHandler(real, 3)); proxy.sync("src-1", options); // 自动带重试

几个必须知道的限制。第一，JDK 动态代理只能代理接口，目标对象必须至少实现一个接口，否则Proxy.newProxyInstance生成的类没法被当成目标类型使用。第二，代理类继承自Proxy，所以它已经没有位置再继承别的类了，这是 Java 单继承导致的天然约束。第三，method.invoke抛出的异常会被包装成InvocationTargetException，如果不拆包直接往外抛，调用方看到的异常类型就变了，这个坑非常隐蔽。

需要代理没有接口的类时，就得靠 CGLIB 这类基于继承的方案，它生成目标类的子类并覆盖方法。代价是 final 类和 final 方法没法代理。Spring AOP 默认策略在不同版本里有变化，早期默认走 JDK 代理，后来默认改成 CGLIB，具体行为受配置项影响，做技术选型时最好在项目里实测确认一下，不要凭记忆下结论。

我自己总结的选型原则是：如果目标本来就是接口调用，优先 JDK 代理，它不依赖额外库、语义干净；如果目标是个没有接口的具体类，或者需要代理类自身的方法，用 CGLIB。另外要注意自调用问题——在同一个类里this.method()调用不会经过代理，事务注解、日志注解都会失效。我见过太多人栽在这个点上，解决办法通常是把方法拆到另一个 Bean 里，或者通过注入自身代理来调用。

4. 接口的工程化治理：幂等、兼容与验证

4.1 接口幂等性怎么落地

幂等的意思是同一个请求执行一次和执行多次，对系统状态的影响相同。查询天然幂等，但下单、扣款、发券这些写操作不处理就会出问题——用户在弱网环境下点了两次提交，或者消息队列重投了一次，订单就多了一笔。

常见的几种实现方式，我按适用场景排一下：

我最常用的组合是唯一索引兜底 + 业务标识去重。唯一索引是最后一道防线，不管上游怎么重试，数据库都不会写进两条；去重表或缓存则负责提前拦截，避免无谓的写入压力。

具体到代码，用状态机约束流转是最干净的做法：

public enum OrderStatus { CREATED, PAID, SHIPPED, FINISHED; public boolean canTransferTo(OrderStatus target) { return switch (this) { case CREATED -> target == PAID; case PAID -> target == SHIPPED; case SHIPPED -> target == FINISHED; case FINISHED -> false; }; } } public void pay(Long orderId) { Order order = orderMapper.selectById(orderId); if (!order.getStatus().canTransferTo(OrderStatus.PAID)) { // 已经是 PAID 或更后面的状态，直接返回成功，保证幂等 return; } // 用带状态条件的更新，避免并发下重复扣款 int rows = orderMapper.updateStatus(orderId, OrderStatus.CREATED, OrderStatus.PAID); if (rows == 0) { return; // 被其他线程抢先更新了 } // 真正的扣款、发券逻辑 }

关键在于那句带旧状态条件的 update，它把"检查"和"更新"合并成了一个原子操作，比先查再改安全得多。这个方法我在高并发场景下用了很多次，比加分布式锁简单，也比纯靠缓存判断可靠。

注意：幂等判断要放在业务逻辑最前面，而不是写完之后。我见过有同事在方法末尾加了幂等校验，结果金额已经扣了才判断出重复，只能再写补偿逻辑，成本翻倍。

4.2 接口版本演进与向后兼容

接口一旦发布出去，改动它的成本就陡然上升。你永远不知道有多少实现在依赖它，尤其是这个接口被当作 SDK 暴露给外部团队时。

Java 层面提供了几个工具。最温和的是新增默认方法，实现类不覆盖也能正常编译运行，这是官方推荐的首选手段。其次是给旧方法加@Deprecated并注明替代方案，给调用方留出迁移时间。最激烈的是删除或改签名，这基本等同于破坏性变更，只能靠大版本号隔离。

我自己的实践约定有这么几条。第一，接口尽量保持窄，方法少意味着变更面小，把易变的部分单独拆成扩展接口。第二，新增能力优先走新接口，比如已有DataSyncService，需要加异步能力时不要往它里面塞方法，而是定义AsyncDataSyncService extends DataSyncService，让需要的实现类去实现。第三，返回值尽量用对象而不是基本类型，这样以后加字段不会破坏签名。第四，参数也尽量用对象封装，sync(SyncOptions options)就比sync(String a, int b, boolean c)好扩展得多，加参数时不用改签名。

还有一个细节：如果接口返回的是集合，务必返回不可变副本或有明确文档说明的可变对象。JDK 的List.of()返回的是不可变列表，调用方一旦尝试add就会抛UnsupportedOperationException。这类问题在接口契约里必须写清楚，否则就是给使用者埋雷。

4.3 接口的测试与压测怎么下手

接口写完不等于能上线，验证环节同样要围绕接口这个契约来做。

单元测试层面，接口的最大好处是可以轻松 Mock。因为调用方依赖的是接口，测试时换成假实现就行，不需要启动数据库和外部服务。我会给每个接口准备一个内存实现，比如InMemoryDataSyncService，它既能用于测试，也能当本地开发的桩。

public class InMemoryDataSyncService implements DataSyncService { private final List<SyncResult> results = new ArrayList<>(); @Override public SyncResult sync(String sourceId, SyncOptions options) { SyncResult r = SyncResult.of(sourceId, options.getBatchSize()); results.add(r); return r; } public List<SyncResult> getResults() { return results; } }

契约测试是另一个值得投入的方向。同一套测试用例跑在接口的多个实现上，保证行为一致。这套东西在替换底层实现时价值极大，我就靠它把存储层从一种方案换成另一种方案，全量用例跑一遍就敢上线。

压测方面，关注的核心指标是 QPS、平均响应时间、P99 响应时间和错误率。P99 比平均值重要得多，平均值好看但 P99 飙高，说明有部分请求在排队或触发慢查询，用户体验照样差。做压测时要注意几个容易忽略的点：

• 连接池大小要跟并发线程数匹配，池子太小会先成为瓶颈；
• 压测机自身的网络和 CPU 要留足余量，别把压测机压成瓶颈；
• 数据量要接近生产规模，几千条数据的查询和几千万条完全是两回事；
• 单接口压测和混合场景压测结果差异很大，有条件尽量做后者。

指标怎么定？没有标准答案，但有个经验做法：先跑出当前系统的极限，再按 60% 到 70% 的水位设告警阈值，给突发留出余量。压测发现问题后，优化顺序一般是先看慢查询和索引，再看锁竞争和线程池配置，最后才考虑加机器。

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

5.1 高频报错速查与定位思路

接口相关的报错有几类特别典型，我把它们整理成了速查表，遇到时可以对照着看：

其中AbstractMethodError和NoSuchMethodError最让人头疼，因为它们编译期完全正常，只有运行到那一行才炸。根本原因几乎都是同一个类或接口存在多个版本。典型场景是：A 模块依赖了core-1.0，B 模块依赖了core-2.0，Maven 的依赖传递调解选了其中一个，导致运行时加载的接口版本和编译时的不一样。

我一般按这个顺序排查：第一步用dependency:tree把依赖树打出来，搜索相关包名，看看有几个版本进来；第二步用dependencyManagement强制统一版本；第三步如果还有问题，检查是不是有第三方包把类打进自己的 jar 里了，这种 shaded jar 最难发现，需要用jar tf看包内容。

另一个高频问题是动态代理下注解失效。事务、缓存、自定义注解几乎都依赖代理，而代理只对"从外部进来的调用"生效。类内部this.foo()这种自调用不会经过代理，注解自然就不起作用了。定位方法很直接：在方法入口打断点，看调用栈里有没有代理类那一层。解决办法是把方法挪到另一个 Bean，或者注入自身引用再调用。

5.2 面试里那几道必问的题怎么答

接口相关的面试题翻来覆去就那么几道，但答法差别很大。我按自己的理解给个思路。

接口能不能有构造器？不能。接口不能被实例化，也就没有构造器。但要注意，接口里的成员变量是隐式的public static final常量，在接口初始化时就会被赋值，这部分逻辑在编译后会放到一个静态初始化块里，和构造器完全是两回事。

一个类能实现多个接口吗？接口能继承多个接口吗？都能。类只能单继承父类，但可以实现多个接口；接口之间用extends可以同时继承多个父接口。这也解释了为什么 Java 8 之后要专门处理默认方法的菱形继承冲突。

抽象类和接口怎么选？按我第 1 节的框架答：抽象类表达"是什么"、能复用代码、支持字段和构造器；接口表达"能做什么"、支持多实现、更利于解耦和替换。实际项目中常常组合使用。

动态代理的实现原理？JDK 代理基于接口，运行期生成一个实现了指定接口和Proxy的子类，把调用转发给InvocationHandler；CGLIB 基于继承，生成目标类的子类并覆盖方法。前者要求有接口，后者要求类和方法非 final。

接口幂等怎么设计？从业务标识入手，讲清楚唯一索引兜底、状态机约束、去重表或令牌机制，并强调幂等判断要前置。如果能举出自己项目里的具体数字，比如"加了带状态条件的更新之后，重复下单从每天几十笔降到零"，说服力会强很多。

真正拉开差距的不是背答案，而是能说出为什么这么选。比如被问到为什么用接口而不是直接调实现类，回答"为了解耦"太空洞，加上"我们当时有三个渠道实现，加新渠道时只新增一个类，调用方零改动"这样的具体场景，分量完全不同。

5.3 几个反直觉的踩坑记录

最后分享几个我在实际项目中遇到过的、说出来你可能不太信的问题。

第一个是默认方法的序列化问题。给一个可序列化的接口加了默认方法后，某些序列化框架在反序列化时会尝试调用它来初始化，结果因为依赖的对象字段还没赋值而抛异常。这个问题的隐蔽之处在于，本地测试完全正常，只有在特定框架组合下才复现。教训是：接口上的默认方法尽量保持无副作用，不要访问实例状态。

第二个是接口常量被内联。接口里的static final常量，如果是编译期常量（比如String字面量、基本类型字面量），javac 会把它的值直接内联到调用方的字节码里。这意味着你改了接口里的常量值，但调用方没有重新编译，它仍然用着旧值。这个坑在跨模块发布时特别容易踩。规避方式是：不要在接口里定义会被内联的编译期常量，需要常量时用枚举或者工具类的静态方法。

第三个是泛型擦除带来的接口冲突。一个类不能同时实现Comparable<String>和Comparable<Integer>，因为擦除后两个接口的方法签名完全一样，编译器会报"继承了两个不同参数化的同名接口"。这个问题在写通用组件时偶尔会遇到，解决办法通常是拆成两个不同的接口，用不同的方法名区分。

第四个是对象序列化后接口版本不匹配。把对象存进缓存，后来给接口加了个方法，反序列化时用的是新版本的类，但缓存里的数据是旧版本写的，字段对不上就出问题。这类问题在缓存和消息队列场景很常见，处理方式是给序列化的数据结构加版本号，或者干脆用独立的 DTO 而不是直接序列化领域对象。

写到这里，我在接口这件事上最深的体会是：接口设计的好坏，在你加第二个实现类的时候才会暴露。只有一个实现类时，怎么设计都看不出问题；等到要替换、要扩展、要加代理的时候，那些当初图省事留下的毛病才会全部冒出来。所以每次定义接口前，我都会逼自己想一下：半年后如果要在不改调用方的前提下换掉这个实现，现在的设计能扛住吗？如果答案是犹豫的，那就再改一版。