接口必须对应明确变化点，如支付方式切换；命名应体现角色（如paymentprocessor），方法聚焦能力，避免万能容器返回值；禁用接口常量，default方法仅限无状态逻辑；spring中用@profile实现可插拔；模块间依赖仅限接口jar，异常类须同包。
为什么接口不是“为了设计而设计”的摆设
接口在Java里最常被误用为“提前写好一堆空方法”，结果后期没人实现，或者所有实现类都只在测试时用一次。真正起作用的接口，必须对应一个明确的「变化点」：比如支付方式可能从 AlipayService 切到 WechatPayService，日志输出可能从控制台切到 FileLogger 或 KafkaLogger。只要这个变化点存在，接口就该存在；否则就是过早抽象。
定义接口时最容易踩的三个坑
接口命名要反映角色，而不是技术动作。比如叫 PaymentProcessor，别叫 IPaymentService（I 前缀是C#习惯，在Java里多余）；方法名要聚焦能力，比如 process(PaymentRequest req)，别写成 doPayment() 这种模糊动词；返回值尽量用具体类型或不可变对象，避免暴露 Map<string object></string> 这类“万能容器”——它会让实现类随意塞字段，破坏契约。
- 接口中不要声明
public static final常量——那是工具类或配置类的职责 - Java 8+ 允许
default方法，但仅限于通用、无状态的辅助逻辑（比如isValid()的默认校验），不能包含业务分支或依赖注入 - 别为了“统一入口”把不相关的功能塞进同一个接口，比如把
sendEmail()和generateReport()都放进NotificationService
Spring环境下如何让接口真正“可插拔”
光有接口没用，关键在运行时能换实现。Spring 的 @Qualifier 和 @Primary 是基础，但更可靠的是按场景分组：比如用 @Profile("prod") 标记生产用的 CloudStorageService 实现，用 @Profile("test") 标记内存版 InMemoryStorageService。这样启动时自动加载，不用改代码。
public interface StorageService {
void save(String key, byte[] data);
byte[] load(String key);
}
@Component
@Profile("test")
public class InMemoryStorageService implements StorageService {
private final Map<String, byte[]> store = new ConcurrentHashMap<>();
// 实现略
}
注意：如果多个实现类都未指定 @Profile，又没标 @Primary，Spring 启动直接报 NoUniqueBeanDefinitionException —— 这不是配置错，是设计漏了决策点。
立即学习“Java免费学习笔记（深入）”；
模块间通过接口通信时，jar 依赖怎么切
核心原则：只让调用方依赖接口所在的 jar，不让其实现类泄漏。比如 order-service 模块需要支付能力，它只引入 payment-api.jar（含 PaymentProcessor 接口），而 payment-alipay.jar 和 payment-wechat.jar 都只依赖 payment-api.jar，且不被 order-service 直接引用。Maven 中用 <scope>provided</scope> 或模块化 requires static 控制可见性。
容易忽略的是异常类型：如果接口方法声明抛出 CustomPaymentException，那这个异常类也必须放在 payment-api.jar 里，否则调用方连编译都过不去——很多人把异常放在实现模块，导致强耦合。
