关于Kotlin顶层属性初始化行为的疑问及官方依据咨询

场景1：顶层属性按顺序初始化，依赖属性已完成初始化 #

class TreeNode(var `val`: Int) {
    var left: TreeNode? = null
    var right: TreeNode? = null
}

val tree2 = TreeNode(2)
val tree1 = TreeNode(3).apply { left = tree2 } 

fun main() {
    println(tree1.left) // 输出 "TreeNode@..."
}

场景2：依赖属性未初始化时，赋值为默认值 #

class TreeNode(var `val`: Int) {
    var left: TreeNode? = null
    var right: TreeNode? = null
}

val tree1 = TreeNode(3).apply { left = tree2 } 
val tree2 = TreeNode(2)

fun main() {
    println(tree1.left) // 输出 "null"
}

场景3：属性默认初始化抛出异常时，触发初始化错误 #

class TreeNode(var `val`: Int) {
    var left: TreeNode? = throw Exception("I am an exception")
    var right: TreeNode? = null
}

val tree1 = TreeNode(3).apply { left = tree2 } 
val tree2 = TreeNode(2)

fun main() {
    /* 输出 "Exception in thread "main" java.lang.ExceptionInInitializerError 
     * Caused by: java.lang.Exception: I am an exception ..."
     */
    println(tree1.left) 
}

我的观察 #

• 顶层属性按从上到下的顺序初始化；
• 若依赖的属性未初始化，则会被替换为默认值。

疑问 #

1. 我的理解是否正确？
2. 若理解正确，是否有官方文档明确说明该行为？
3. 为何选择用默认值替代未初始化的依赖属性，而非触发编译错误或运行时错误提示tree2未初始化？

解答 #

1. 理解的正确性补充

你的核心观察是正确的，但需要补充细节：

• 顶层属性确实严格按照代码书写的从上到下顺序完成初始化，这属于类加载阶段的静态初始化逻辑（对应Java的<clinit>方法）。
• 当引用未初始化的顶层属性时，仅可空类型会被替换为类型默认值（如null）；如果是不可空类型，会直接触发UninitializedPropertyAccessException运行时异常，不会使用默认值。

2. 官方文档的明确说明

Kotlin官方文档明确规定：顶层属性与对象表达式的初始化是线程安全的，且遵循从上到下的执行顺序。对于初始化期间访问未完成初始化的属性的场景，文档指出：可空类型会返回其默认值，不可空类型则抛出未初始化访问异常。

3. 设计逻辑说明

选择此行为而非编译错误的原因主要有三点：

• 兼容循环依赖场景：部分复杂业务场景中可能存在顶层属性的循环依赖，允许默认值初始化可以避免编译阶段直接阻断程序，保留运行时处理的可能性。
• 对齐Java初始化逻辑：Java静态变量初始化同样存在“先赋予默认值，再执行显式初始化”的行为，Kotlin为保持与Java的互操作性，沿用了这一逻辑。
• 符合可空类型设计：对于可空类型，null本身是合法的状态，将未初始化的可空属性视为null符合类型系统的设计，开发者可通过空安全检查处理此类情况。

内容的提问来源于stack exchange，提问作者hj-core