Java的extends仅支持单继承，可链式继承但不允许多类继承；继承public/protected及包内default成员，不可见private成员；构造器不被继承，static成员可继承但不可重写。
Java里extends到底能继承什么
Java的extends只允许单继承，且只能继承一个类（不能多类），但可以无限层链式继承（A extends B，B extends C）。它继承的是父类的public和protected成员，以及包内可见的default成员——但private字段和方法完全不可见，子类里写this.privateField会直接编译报错。
常见错误现象：Cannot resolve symbol 'xxx'，尤其当父类用private修饰字段、又在子类里试图直接访问时；或者误以为extends能继承构造器——其实构造器从不被继承，子类必须显式调用super()（或隐式调用无参super()）来初始化父类部分。
- 如果父类只有带参构造器，子类必须写
super(xxx)，否则编译失败 -
static成员属于类本身，可被继承但无法被重写（只能隐藏），调用时看引用类型而非实际类型 - 接口不能用
extends继承类，只能用implements；类也不能extends接口
为什么Java不允许类多继承
不是语法懒，是为避免“菱形继承”带来的歧义。比如类A有method()，B和C都extends A并各自重写了它，D同时想继承B和C——那d.method()该调谁的？C++靠虚继承解决，但代价是复杂性和运行时开销。Java选择用单继承+接口多实现来平衡：子类只有一个父类骨架，行为扩展靠implements多个接口，接口中默认方法（default）还能提供可选实现。
性能影响很小，但设计意图明确：类定义“是什么”，接口定义“能做什么”。强行用继承模拟多重角色，后期修改成本高，比如把Runnable逻辑硬塞进某个业务类的继承链里，很快就会卡死。
立即学习“Java免费学习笔记（深入）”；
- 替代方案：组合优于继承。用
private final SomeService service+ 委托调用，比extends SomeService更灵活、更易测试 - 若真需要复用代码，优先考虑提取为工具类或默认方法，而不是拉长继承链
extends后子类怎么安全覆写父类方法
覆写（override）不是加个@Override注解就完事。JVM在运行时根据对象实际类型决定调用哪个版本，但编译期检查很关键：方法签名（名称+参数类型+顺序）必须严格一致，返回类型需协变（如父类返回Object，子类可返回String），访问权限不能更严格（public不能改成protected）。
容易踩的坑：static方法看似能“覆写”，实则是隐藏（hiding）——调用看引用类型，不是实际类型；还有参数类型写成Integer vs int，表面一样，实则构成重载而非覆写，@Override会直接报错。
- 务必加
@Override注解，让编译器帮你捕获签名不匹配 - 不要在构造器中调用可能被覆写的方法（包括
this.xxx()），父类字段还未初始化，可能NPE或逻辑错乱 - 覆写
toString()、hashCode()、equals(Object)时，记得同步更新逻辑，尤其涉及继承字段时
继承链过深时的实际麻烦
超过3层（如Animal → Mammal → Dog → Poodle）的继承，在真实项目里往往意味着维护困难。父类一改，所有下游都得测；某层加了个final方法，子类立刻失去定制能力；更隐蔽的是，IDE自动补全会列出几十个继承来的方法，真正该用的反而被埋掉。
兼容性影响不大（JVM对深度没限制），但可读性和调试成本飙升。比如NullPointerException堆栈里出现at com.xxx.BaseHandler.handle(BaseHandler.java:123)，你得顺着extends链翻5个文件才能定位到真正出问题的逻辑。
- 新建子类前先问：这个“是”关系是否稳定？会不会明天就被拆成两个独立角色？
- 已有深链想重构？优先把中间层的通用逻辑抽成
abstract类或组合组件，而非继续向下延伸 - 单元测试里mock父类行为很难受——用继承就得测整个链，用组合只需mock接口
继承不是不用，而是它的边界比初学者想的窄得多。真正难的不是语法，是判断“这里该用extends，还是该换个活法”。
