子类重写方法后父类逻辑变更不生效，因Java无协同进化机制；子类需显式调用super()、适配模板方法、处理字段访问权限变更；default方法适用于接口演进；@Deprecated不影响运行但需注意语义；提取共性方法前须审慎判断职责归属。
子类重写方法时，父类逻辑变更为什么没生效
Java 里没有“协同进化”这种机制——父类改了，子类不会自动同步。子类重写的 toString()、calculate() 这类方法，一旦声明，就完全接管该方法的实现，和父类后续怎么改无关。
常见错误现象：NullPointerException 或计算结果不对，排查半天发现是父类新增了初始化逻辑（比如在 init() 中设置 config 字段），但子类构造器没调用它，也没手动补上。
- 子类构造器必须显式调用
super(...)，否则默认走无参父构；如果父类删了无参构造，子类编译直接报错 - 父类新增模板方法（如
templateMethod()调用doStep1()和doStep2()），子类只重写了doStep1()，却漏掉doStep2()的适配，导致流程中断 - 父类把某个字段从
protected改成private并提供getXXX()，子类原来直接读字段的地方会编译失败
什么时候该用 default 方法而不是继承
Java 8+ 接口支持 default 方法，本质是“协议层可扩展，实现层不强制更新”。适合功能演进但不想破环现有子类的场景。
使用场景：给已有接口添加新能力，比如给 List 衍生接口加个 filterThenMap()，所有实现类自动获得该方法，无需修改子类代码。
立即学习“Java免费学习笔记（深入）”；
-
default方法不能访问子类私有成员，也不能替代protected钩子方法 - 如果子类已定义同签名方法，
default会被忽略——不是覆盖，是被屏蔽 - 多个接口含同名
default方法，实现类必须显式重写，否则编译报错：class A inherits unrelated defaults for methodX() from types B and C
父类加了 @Deprecated，子类重写后还能用吗
能用，但 IDE 和编译器仍会标黄警告；更关键的是：@Deprecated 不影响运行时行为，也不阻止子类继续调用或重写。
容易踩的坑在于语义误判：以为加了 @Deprecated 就等于“马上要删”，其实 JDK 里很多 @Deprecated 方法活了十多年。真正危险的是父类删掉方法本身，子类编译不过。
- 子类重写一个已被
@Deprecated的父类方法，自己也可以加@Deprecated，但需同步更新 Javadoc 说明替代方案 - 如果父类方法被标记为
@Deprecated(since = "17")，子类调用处会出现 warning，但不会触发-Werror（除非额外配置） - 反射调用
Class.getMethod("oldMethod")在方法被删除后才抛NoSuchMethodException，不是加@Deprecated时
IDE 提示 “Method can be moved to superclass” 是不是该立刻提取
不一定。这个提示只是静态分析发现多个子类有相同实现，但它不判断语义是否真该归属父类。
性能影响很小，但抽象层级错位后果严重：比如把 HTTP 请求重试逻辑从 PaymentService 和 NotificationService 提到共同父类 BaseService，看似 DRY，实则让日志上报服务也背上了 HTTP 重试的依赖和配置。
- 先确认该逻辑是否属于“所有子类共有的责任”，而不是“碰巧一样”的偶然重复
- 检查父类是否已有类似职责边界；如果父类是领域无关的（如
Object子类），强行塞业务逻辑会污染抽象 - 提取后，注意子类原实现中隐含的定制点（比如某子类多捕获了一个
TimeoutException），这些得转成钩子或策略参数
真正难的从来不是语法能不能动，而是“这个行为到底属于谁的契约”。父类改一行，子类崩一片，问题往往出在最初设计时对职责边界的模糊判断。
