接口定义能力（能做什么），继承表达本质（是什么）；接口无状态、字段须public static final，default方法禁改共享状态；多层继承应转为组合+接口；方法名用明确动词，返回接口类型而非具体实现。
Java 中接口和继承不是非此即彼的选择，而是协作关系：接口定义“能做什么”，继承表达“是什么”。滥用 extends 替代 implements，或把接口当类用，是多数设计腐化的起点。
接口不该有状态，更不该有可变字段
接口里声明 public static final 常量没问题，但一旦出现 public int counter = 0 这类字段，就违背了接口契约本质——它不再是能力声明，而成了伪基类。JDK 8+ 虽支持 default 方法，但若在其中修改共享状态（比如操作静态集合），会导致实现类间意外耦合。
- 所有字段必须是
public static final，且值为编译期常量（如String字面量、int字面量） - 避免在
default方法中访问或修改静态变量、外部单例、系统属性等共享资源 - 若需默认行为带状态，应交由抽象类处理，而非塞进接口
继承深度超过两层时，优先考虑组合 + 接口
当你发现类层级是 Animal → Mammal → Carnivore → Lion，且每层只加一两个方法，大概率已掉进继承陷阱。Java 不支持多继承，但一个类可实现多个接口；而组合天然支持运行时替换，比继承更易测试和扩展。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 把“会飞”“会游泳”“有毛发”等能力拆成
Flyable、Swimmable、Furry接口 - 用字段持有具体策略对象（如
private MovementStrategy movement;），而非靠父类传递逻辑 - 抽象类仅用于封装**高度复用的模板逻辑**（如
AbstractList的add模板），而非为了“看起来像父子”
接口方法命名要聚焦动词，避免暴露实现细节
接口名应是名词（Comparable、Runnable），方法名则必须是动词短语，且不暗示内部如何做。比如 getCacheMap() 暴露了 Map 实现，后续想换成 ConcurrentHashMap 或 Redis 客户端就会破坏契约；而 put(K key, V value) 和 get(K key) 是安全的。
立即学习“Java免费学习笔记（深入）”；
- 禁止返回具体集合实现类（如
HashMap、ArrayList），统一用Map、List等接口类型 - 避免
initXXX()、doXXX()这类模糊动词，改用start()、connect()、validate()等明确语义的名称 - 若需配置，提供
withTimeout(long ms)这类构建式方法，而非暴露 setter
public interface HttpClient {
Response execute(Request request);
// ✅ 好：行为抽象，不绑定实现
HttpClient withTimeout(long millis);
// ❌ 坏：暴露内部结构
// Map<String, String> getHeaders();
}
接口与继承的边界，往往不在语法限制里，而在你第一次犹豫“这个方法该放接口里，还是留给子类自己写”时。真正难的不是写对代码，而是每次新增一个 extends 或 implements 时，能否清晰说出它解决的是哪个具体问题，而不是“别人都这么写”。
