Kotlin基类初始化访问派生类重写属性的场景与open属性正确用法

为什么示例代码会输出null #

• 首先明确：Kotlin中所有被open修饰的属性、方法，执行时遵循 虚分派 规则：不会根据当前代码所属的类静态绑定实现，而是根据对象的实际运行时类型，优先匹配最派生类（也就是这里的Derived）的重写实现。
• 你创建Derived("Test2")时的实际执行链路是完全固定的：
  1. 先在内存里划分出属于Derived类实例的整块空间，把所有字段（包括继承自Base的something字段槽位）全部初始化为默认值（引用类型为null）——这一步在任何构造代码执行前完成
  2. 触发基类Base的构造逻辑：依次执行Base自己的属性初始化、Base的init块
  3. 等Base的构造逻辑全部跑完，再回头执行Derived类的属性初始化、Derived自己的init块
• 这里的冲突点完全来自 虚分派的无隔离特性：
  Base的init块里写的println(something)，因为something是open属性，且被Derived重写，这个调用根本不会访问Base自己的something实现，而是直接跳转到Derived类重写的something的getter方法。但此时整个流程还在Base的构造阶段，Derived类的属性初始化逻辑还没开始跑，getter取到的是刚划分出来的内存里默认的null值，最终打印结果自然是null。
• 额外澄清一个常见误区：很多人以为这个场景下会打印Base自己定义的"Test1"，但实际上当Derived重写了something属性后，创建Derived实例时，Base类里open val something = "Test1"的初始化代码是完全不会执行的——因为属性重写是同一个内存槽位的覆盖，不是两个独立字段，Base的赋值逻辑会被派生类的同签名属性直接跳过。

文档描述的「基类初始化使用派生类重写属性」到底是什么场景 #

你写的这段示例代码就是最标准的触发场景，没有任何特殊的复杂依赖，触发条件完全符合文档描述：

• 基类在构造链路（构造器、属性初始化器、init块）中，直接或间接访问了一个被open修饰的成员
• 派生类重写了这个open成员，且重写的实现依赖派生类自己的属性初始化值
• 基类执行到初始化代码时，虚分派逻辑跳转到派生类的未初始化实现，拿到默认值，引发逻辑错误
  至于“基类为什么能访问到派生类的重写属性”——本质是Kotlin/Java的虚分派设计没有给构造阶段做特殊的调用隔离，不会因为当前代码在基类的构造上下文里，就跳过派生类的重写实现。所有对open成员的访问，不管写在哪个类的代码里、在执行流的哪个位置，都会按对象的实际类型匹配最派生的实现。

open属性的正确使用方式 #

既然基类构造阶段访问open成员会有未初始化的风险，那open成员的使用只要严格遵守「不在构造链路碰open成员」的原则就完全安全，常见的合规用法有三种：

• 把open成员的访问逻辑放到普通实例方法里，不要放到构造阶段执行的代码块中。比如把Base里的init { println(something) }改成普通方法fun printSomething() = println(something)，等整个对象的所有初始化逻辑跑完、外部调用这个方法时，虚分派走到派生类的getter，此时派生类的属性已经完成初始化，不会拿到null。
• 如果基类确实需要在初始化阶段拿到配置值，不要用open属性做传递，改成在基类的构造器中声明非open的入参。比如改造代码为：

  open class Base(initValue: String) {
      init {
          println(initValue)
      }
  }
  class Derived(override val something: String): Base(something)
  

  这里的initValue是基类构造器的入参，不是open成员，不会被重写，也不会触发虚分派，不存在未初始化的问题。
• 基类自己的初始化逻辑，只依赖自身定义的非open成员，不要依赖open成员的派生类实现。基类的open成员设计成供外部调用的扩展点，而不是基类内部初始化流程的依赖。

内容的提问来源于stack exchange，提问作者JockyCracker