能，Java 8起接口可写default和private方法，Java 9支持private辅助方法，static方法需有实现体，但均不可为final或访问实例字段。
接口里能写具体方法吗？Java 8之后的限制要搞清
能，但有严格条件。Java 8 引入 default 方法，允许在接口中提供默认实现；Java 9 又支持 private 辅助方法。但这些方法不能是 static（Java 8+ 允许 static，但必须有实现体）或 final，也不能访问实例字段。
常见错误是把 default 方法当成普通类方法来重载逻辑，结果子类忘记重写导致行为不符合预期。比如：
interface Drawable {
default void draw() { System.out.println("default draw"); }
}
class Circle implements Drawable {
// 没重写 draw()，调用的就是 default 版本
}
真正需要强制子类实现的，还是得靠抽象方法——接口里没加 default 或 static 的方法，一律是 public abstract。
什么时候必须用抽象类，而不是接口？
当你要共享状态或复用非静态代码逻辑时，抽象类是唯一选择。接口不能有构造器、不能有实例字段、不能有 this 引用，因此无法维护对象生命周期或封装内部状态。
立即学习“Java免费学习笔记（深入）”；
典型场景包括：
- 需要定义 protected 字段供子类继承使用（如缓存容器、配置上下文）
- 构造器中有初始化逻辑（如注册监听器、加载资源）
- 多个子类共用一套模板方法（
templateMethod()调用若干abstract步骤） - 已有类已继承某个父类，但还想复用某套行为——这时只能实现接口，不能继承第二个类
例如日志组件基类：AbstractLogger 可能持有 Level threshold 和 Appender[]，这些没法塞进接口。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
接口多实现 vs 抽象类单继承：设计权衡在哪？
Java 不支持多继承，但允许一个类实现多个接口。这意味着“能力组合”适合用接口（如 Runnable + Serializable + AutoCloseable），而“本质归属”更适合抽象类（如 InputStream 是所有字节输入流的共同祖先）。
容易踩的坑：
- 为图方便把本该是“is-a”关系的模型硬拆成接口（比如
Dog extends Animal写成Dog implements Animal），破坏语义一致性 - 在接口中添加新
default方法，导致下游实现类意外改变行为（尤其未测试覆盖时） - 抽象类暴露过多 protected 方法，导致子类过度耦合父类实现细节
判断标准很简单：如果两个类型之间能说“X 是一种 Y”，优先考虑抽象类；如果说“X 能做 Y 这件事”，就用接口。
Java 14+ 密封类（sealed classes）出现后，还怎么选？
密封类不是替代接口或抽象类，而是补充控制继承范围的工具。它和抽象类常配合使用——比如你定义 abstract sealed class Shape permits Circle, Rect, Triangle，既保留抽象类的共享逻辑能力，又限制谁能继承。
这时候接口依然负责定义契约（如 AreaMeasurable、Resizable），抽象类负责共享实现，密封类负责收口扩展点。三者分工更清晰了，但也意味着设计决策链条变长：先想清楚哪些行为要开放（接口）、哪些状态/逻辑要复用（抽象类）、哪些子类是受信且有限的（sealed）。
最容易被忽略的是兼容性成本：一旦把类声明为 sealed，所有子类必须显式用 permits 或 non-sealed 声明，老项目迁移时需同步改源码，IDE 支持也还在完善中。
