接口更灵活因其分离“做什么”与“怎么做”，调用方仅依赖行为契约；实现可替换（如MySQL/MongoDB/Mock）、测试易模拟、编译期解耦；需注意实现方法必须public、多default方法须显式重写；非所有场景都需接口，应聚焦可变点。
接口为什么比直接调用类更灵活
因为接口把“做什么”和“怎么做”彻底分开——调用方只依赖行为契约，不关心具体是哪个类在干活。比如你写 UserRepository.findById()，背后可以是 MySQL 实现、MongoDB 实现，甚至是个内存 Mock 实现，只要它们都实现了同一个接口，你的业务代码一行都不用改。
- 替换实现零成本：换数据库？改个
new对象或 Spring 的@Bean注入就行 - 测试更容易：用匿名内部类或 Mockito 模拟接口，不用启动真实数据库
- 编译期解耦：类 A 只持有
UserRepository引用，根本不知道MySQLUserRepository这个类存在
implements 时最容易踩的访问权限坑
很多人写实现类时把方法写成包私有（不加 public），结果编译报错：attempting to assign weaker access privileges。这是因为接口里所有方法默认是 public abstract，而实现类里对应方法必须至少是 public，不能降级。
- 错误写法：
void findById(Long id) { ... }（缺public） - 正确写法：
@Override public User findById(Long id) { ... } - IDE 通常会自动补全
public，但手写或重构时容易漏
多接口实现如何避免行为冲突
一个类实现多个接口（如 Runnable + Serializable + 自定义 Validatable）很常见，但要注意默认方法同名时的冲突规则：如果两个接口都提供了同签名的 default 方法，编译器会报错，**必须在实现类中显式重写该方法**。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 例如
Flyable和Swimmable都有default move() { ... }→ 编译失败 - 解决方式：在实现类中明确写
@Override public void move() { ... }，自己决定逻辑 - 静态方法不会冲突，因为只能通过接口名调用，如
Flyable.describe()
接口不是万能的：什么时候不该硬套接口
不是所有抽象都需要接口。如果只有一个实现类、且短期内绝无扩展可能，强行抽接口反而增加认知负担和文件数量。接口的价值在于「变化点」——当行为可能被替换、被模拟、被组合时才值得抽象。
立即学习“Java免费学习笔记（深入）”；
- 适合接口：数据访问层、事件监听器、策略算法（如不同支付方式）
- 不适合接口：工具类（
StringUtils）、纯数据载体（UserDTO）、临时脚本逻辑 - 一个信号：如果你写完接口后，90% 的调用都只用一个实现类，且没有测试/框架/配置驱动的需求，先别急着加接口
public 忘写了，或者两个 default 方法撞上了。 
