Java继承中final字段初始化必须由父类构造器或子类显式完成，禁止this逃逸破坏JMM可见性，静态final属类加载阶段，实例final严格绑定子类构造路径。
在Java继承体系中，final字段的初始化和可见性不是孤立问题，而是与构造顺序、this逃逸、JMM语义深度耦合的关键环节。它既影响编译是否通过，也决定多线程下其他线程能否看到正确值——稍有不慎，就会出现“编译期安全但运行时出错”的陷阱。
继承链中final字段必须由子类显式初始化
父类声明的final字段，若未在父类构造器中完成赋值，则子类构造器必须确保其被初始化。Java不支持“延迟到子类再赋值”的隐式传递逻辑。
- 父类中声明
protected final String id;且无构造器赋值 → 编译失败，除非父类提供带参数的构造器并完成初始化 - 子类不能靠“继承”自动获得final字段的初始化义务豁免；哪怕字段是
protected或package-private，子类构造器仍需参与赋值流程 - 常见错误：子类调用
super()后试图在自己构造器中给父类final字段赋值 → 编译报错“cannot assign a value to final variable”
构造器链中this逃逸会破坏final字段的可见性保证
final字段的线程安全可见性（JMM中的初始化安全性）有一个前提：对象构造完成前，this引用不得泄露。而在继承场景下，this逃逸极易发生在父类构造器中调用可被重写的方法时。
- 父类构造器中调用
init()，而该方法被子类重写 → 子类方法内访问自身尚未初始化的final字段，可能读到默认值（如0、null） - 即使父类final字段已在父类构造器中赋值，若子类在重写方法中读取它，仍可能因指令重排序或未同步发布，看到未更新的值
- 解决方案：父类中被子类依赖的初始化逻辑，应使用
private或final方法，避免虚方法调用
静态final字段不受继承影响，但实例final字段受构造顺序严格约束
静态final字段属于类而非实例，其初始化只发生在类加载阶段，与继承无关；而实例final字段的初始化时机，严格绑定在每个具体子类的构造路径上。
立即学习“Java免费学习笔记（深入）”；
-
static final字段可在父类静态块中初始化，子类无需、也不能再次赋值 - 子类构造器执行前，父类构造器必须先完成——这意味着父类中声明的实例final字段，必须在父类构造器返回前完成初始化
- 若父类有多个构造器，且某些构造器未初始化某个final字段，而子类恰好调用该构造器 → 编译失败，与是否继承无关
Java 25增强：条件分支中初始化final字段，但继承上下文仍需全局路径覆盖
Java 25允许在if/else或switch中为final字段赋值，前提是所有控制流路径都确保一次且仅一次赋值。但在继承结构中，这一能力需跨类验证。
- 父类构造器若含条件分支初始化final字段，编译器会检查每条路径；子类调用
super(...)时，必须保证传入参数能触发其中一条完整路径 - 子类自身新增final字段，同样需在自己的构造器中完成初始化——不能依赖父类逻辑“顺带处理”
- record类虽自动处理final字段，但不支持继承（record天生final），因此该便利在继承体系中不可用
