嵌套类变量可见性由类加载顺序、初始化时机和作用域规则共同决定；静态成员按首次主动使用触发，静态内部类不引发外部类初始化，实例内部类依赖外部类实例，局部内部类仅捕获effectively final变量。
嵌套类中变量的可见性层级，本质上由类加载顺序、初始化时机和作用域规则共同决定。代码块（静态块、实例块）的执行顺序，是观察和验证这一层级最直接的手段。
静态成员与静态代码块的加载优先级
外部类的静态成员和静态代码块在类首次主动使用时执行，且只执行一次；内部类（包括静态内部类）的静态部分，要等到该内部类被首次主动引用时才触发加载。
- 外部类的 static final 常量（编译期常量）会被内联，不触发外部类初始化
- 静态内部类中定义的 static 变量，不会导致外部类初始化，但会触发该内部类自身的静态初始化
- 用 Class.forName("Outer$StaticInner") 显式加载静态内部类，会执行其静态块，但不会执行 Outer 的静态块（除非 Outer 尚未初始化且被间接依赖）
实例代码块与构造器中的嵌套类访问链
非静态内部类依赖外部类实例，因此它的创建必然发生在外部类实例已存在之后。此时，实例代码块和构造器中对内部类变量的访问，需注意“声明位置”和“赋值时机”的差异。
- 外部类的实例块先于构造器执行，但晚于静态初始化
- 在实例块中 new Inner()，此时 Inner 的字段若引用外部类的 尚未赋值的字段（比如字段声明在实例块之后），将得到默认值（如 null、0）
- 内部类中访问外部类的 this.field 是安全的，但若通过方法调用间接读取，而该方法在外部类字段初始化前被调用，仍可能读到默认值
局部内部类与匿名类的变量捕获限制
它们只能捕获所在方法中被声明为 final 或 effectively final 的局部变量。这不是加载顺序问题，而是编译期可见性约束——本质是把变量值“快照”进内部类实例字段中。
- 变量在内部类定义前必须完成初始化（否则编译报错）
- 即使外部类实例已完全初始化，若局部变量未 final，匿名类无法访问——这是作用域+生命周期的双重限制
- 可借助包装对象（如 AtomicInteger、自定义 Holder）绕过 final 限制，实现运行时可见性更新
实战调试建议：用日志锚定初始化节点
在每个静态块、实例块、构造器、内部类字段初始化处插入带类名和序号的日志，能清晰还原 JVM 实际执行流。
- 例如：System.out.println("[Outer.static] loaded");
- 配合 -XX:+TraceClassLoading JVM 参数，观察类加载时序
- 对关键字段加 volatile 或使用 debugger 观察字段值变化点，区分“声明”“初始化”“赋值”三个阶段
