final成员变量必须在构造方法结束前完成初始化，否则编译报错；只能在声明处、构造器内或初始化块中赋值，且每个构造路径都必须覆盖所有final字段。
final 成员变量必须在构造方法结束前完成初始化
Java 中 final 修饰的成员变量不是“声明即固定”，而是“首次赋值后不可再改”——但这个“首次赋值”有硬性时机要求：必须在对象构造完成前发生。如果漏掉初始化，编译器会直接报错 variable might not have been initialized，而不是等到运行时。
常见错误是把初始化逻辑放在普通方法里，比如：
class Config {
final String token;
Config() { /* 没初始化 token */ }
void loadToken() { token = "abc"; } // 编译失败：无法在非构造路径中赋值
}- 只能在声明处直接赋值：
final String token = "hardcoded"; - 或在每个构造方法内显式赋值（包括所有重载构造函数）
- 若使用 this(...) 调用其他构造器，被调用的构造器必须完成所有
final字段的初始化
使用构造器参数 + this 赋值是最安全的初始化方式
依赖外部传入值初始化 final 字段，能兼顾灵活性与不可变性。关键点在于：每个构造路径都必须覆盖全部 final 字段，且不能靠条件分支“跳过”某字段。
class User {
final String id;
final String name;
User(String id) {
this.id = id;
this.name = "anonymous"; // 必须在这里赋值，不能留空
}
User(String id, String name) {
this.id = id;
this.name = name; // 同样必须赋值
}
}- 避免在构造器中调用可被子类重写的方法（如
this.init()），否则子类可能在父类字段未初始化完时访问final字段 - 不要用三元运算符或方法调用“延迟”初始化，例如
final int size = computeSize();是允许的，但computeSize()内部不能依赖未初始化的其他final字段 - 如果字段类型是引用类型（如
final List<string></string>），final只锁住引用本身，不锁住对象内部状态——仍需用Collections.unmodifiableList()等进一步保护内容
静态 final 和实例 final 的初始化时机完全不同
容易混淆的是 static final 字段——它属于类，初始化发生在类加载阶段，和构造器完全无关。而实例 final 字段属于每个对象，必须由每个对象的构造过程独立完成初始化。
-
static final可在声明处、静态代码块中初始化，不能在构造器中赋值 - 实例
final不能在静态代码块中初始化（编译报错：cannot assign a value to final variable） - 二者共存时，静态字段先就位，实例字段后按构造顺序初始化——但它们互不影响
IDE 和编译器对 final 初始化的检查有盲区
javac 会严格校验所有构造路径是否覆盖 final 字段，但某些情况它“看不透”：
- try-catch 块中初始化：如果 catch 块没给
final字段赋值，即使 finally 里写了，也会报错 - 循环中赋值：编译器不认为 for/while 循环“必然执行”，即使逻辑上一定走一次，也会提示未初始化
- Lombok 的
@RequiredArgsConstructor会自动生成只含final字段的构造器，但如果类里还有非final字段参与逻辑，容易误以为构造已完备
最稳妥的做法：删掉所有构造器，只保留一个全参构造器，并逐个字段显式赋值——哪怕暂时用 null 占位，也能快速暴露漏初始化的问题。
