委托机制的源码级剖析

组合优于继承：委托模式的设计动机

在前面两篇文章中，我们深入了解了 Kotlin 类的构建机制以及 data class / sealed class 的编译产物。在继承体系中，我们看到 Kotlin 默认 final 的设计是为了对抗脆弱基类问题。但这引出了一个根本性的软件工程问题：如果继承是危险的，那代码复用该怎么做？

GoF（Gang of Four）在《设计模式》中给出了经典答案：优先使用组合（Composition），而非继承（Inheritance）。但在 Java 中，组合意味着手动编写大量的"转发方法"——如果一个接口有 10 个方法，你就要写 10 个一模一样的转发调用。这种机械性的重复代码不仅枯燥，还容易在接口演进时漏掉新增方法。

想象你是一家公司的前台。客户打来的每一通电话，你都要亲自接听，然后说"请稍等，我帮您转接"，再一个个拨给对应的部门。如果公司有 50 个部门，你就要记住 50 种转接方式。Kotlin 的委托就像安装了一套自动转接系统——你只需要说"这个号段的电话全部转给财务部"，系统自动帮你处理所有转接，你只需要在某几个特殊电话上亲自处理。

Kotlin 用 by 关键字为委托模式提供了语言级别的一等支持，彻底消灭了这些样板代码。这套委托机制分为两大体系：类委托（Class Delegation） 和属性委托（Delegated Properties），本文将从编译产物的角度逐一拆解它们的底层实现。

类委托（Class Delegation）：by 关键字的编译原理

基本语法与编译产物

类委托允许你将接口的实现"交给"另一个对象。语法非常简洁：

interface Printer {
    fun print(content: String)
    fun status(): String
}

class LaserPrinter : Printer {
    override fun print(content: String) = println("🖨️ 激光打印: $content")
    override fun status(): String = "就绪"
}

// 通过 by 关键字，将 Printer 接口的实现委托给 printer 对象
class Office(private val printer: Printer) : Printer by printer

这段 Kotlin 代码，编译器会将其转换为以下字节码（等效 Java）：

public final class Office implements Printer {
    // ① 编译器保存委托对象的引用
    private final Printer printer;

    public Office(Printer printer) {
        this.printer = printer;
    }

    // ② 编译器为接口的每个方法生成转发方法
    public void print(String content) {
        this.printer.print(content);  // 直接转发给委托对象
    }

    public String status() {
        return this.printer.status(); // 直接转发给委托对象
    }
}

编译器在这里做了三件事：

1. 存储委托对象：生成一个 private final 字段来持有委托实例
2. 生成转发方法：为接口中的每一个方法生成一个实现，方法体就是调用委托对象的对应方法
3. 使用标准字节码指令：转发调用使用的是 INVOKEINTERFACE 指令，和你手写的委托代码完全一样

没有反射、没有动态代理——一切都是编译时的静态代码生成，性能与手写转发代码完全等价。

与 Java 手动委托的对比

让我们直观地对比一下这种差异。假设需要委托一个有 5 个方法的接口：

// Java：手动委托——5 个方法就要写 5 个转发
public class Office implements Printer {
    private final Printer printer;

    public Office(Printer printer) { this.printer = printer; }

    @Override public void print(String content) { printer.print(content); }
    @Override public String status()            { return printer.status(); }
    @Override public void configure(Config c)   { printer.configure(c); }
    @Override public void reset()               { printer.reset(); }
    @Override public int pageCount()            { return printer.pageCount(); }
}

// Kotlin：一个 by 关键字搞定——编译器自动生成所有 5 个转发方法
class Office(printer: Printer) : Printer by printer

当接口新增方法时，Java 版本需要手动添加转发方法（否则编译不通过），Kotlin 版本则无需改动——编译器会自动为新方法生成转发代码。

选择性覆写：在委托基础上定制行为

类委托的威力在于：你可以"大部分行为交给委托对象，只在需要的地方自己动手"：

class LoggingPrinter(private val delegate: Printer) : Printer by delegate {
    // 仅覆写 print 方法，添加日志功能
    override fun print(content: String) {
        println("📝 [LOG] 开始打印: $content")
        delegate.print(content)  // 手动调用委托对象
        println("📝 [LOG] 打印完成")
    }
    // status() 仍然自动委托给 delegate
}

编译器的处理策略很清晰：

• 你覆写了的方法：使用你的实现，不生成转发代码
• 你没覆写的方法：自动生成转发代码

这在字节码中的体现是：

public final class LoggingPrinter implements Printer {
    private final Printer delegate;

    // print —— 使用你的自定义实现
    public void print(String content) {
        System.out.println("📝 [LOG] 开始打印: " + content);
        this.delegate.print(content);
        System.out.println("📝 [LOG] 打印完成");
    }

    // status —— 编译器生成的转发方法
    public String status() {
        return this.delegate.status();
    }
}

核心陷阱：自调用不会被拦截

这是理解类委托最关键的认知——委托不是继承，委托对象内部的自调用不会被外部类拦截。

interface Worker {
    fun doWork()
    fun report()
}

class RealWorker : Worker {
    override fun doWork() {
        println("开始工作")
        report()  // 内部自调用——调的是自己的 report()
    }

    override fun report() {
        println("RealWorker 报告")
    }
}

class SupervisorWorker(worker: Worker) : Worker by worker {
    override fun report() {
        println("SupervisorWorker 报告")  // 试图覆写 report
    }
}

fun main() {
    val supervised = SupervisorWorker(RealWorker())
    supervised.doWork()
}

输出结果：

开始工作
RealWorker 报告    ← 不是 "SupervisorWorker 报告"！

为什么？ 让我们从字节码层面分析调用链：

supervised.doWork()                     
    ↓ 编译器生成的转发方法
this.delegate.doWork()                  ← delegate 是 RealWorker 实例
    ↓ RealWorker.doWork() 内部
this.report()                           ← this 是 RealWorker，不是 SupervisorWorker
    ↓
RealWorker.report()                     ← 调用自己的 report()，而非外部覆写

根本原因在于：委托对象（RealWorker）是一个完全独立的实例。它不知道外面有个 SupervisorWorker 包裹着自己，更不知道 report() 被覆写了。当 RealWorker 内部调用 this.report() 时，this 指向的是它自己，不是 SupervisorWorker。

在继承关系中，情况完全不同——子类覆写的方法会通过**虚方法表（vtable）**被正确分派，this 始终指向实际对象。

这就像你给秘书（委托对象）一份工作流程表，说"按这个流程来，但是签字环节由我来"。秘书在执行流程的过程中，遇到需要签字的步骤，他看了看自己的流程表，发现上面写着"本人签字"——于是他自己签了。他根本不知道"签字应该由你来做"这件事，因为你只能替换从外部调用他的入口，无法修改他内部的流程。

何时使用类委托

属性委托（Delegated Properties）：属性的"管家"

getValue() / setValue() 的约定

属性委托是 Kotlin 的另一大委托机制——它允许你将一个属性的 getter/setter 逻辑"外包"给一个委托对象。编译器要求这个委托对象遵循一套固定的约定：

class Delegate {
    // 用于 val 属性（ReadOnlyProperty）
    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
        return "属性 '${property.name}' 的值"
    }

    // 用于 var 属性（ReadWriteProperty）
    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
        println("属性 '${property.name}' 被设为 '$value'")
    }
}

class Example {
    var message: String by Delegate()
}

两个核心参数：

• thisRef：属性所在的宿主对象（即 Example 的实例）。如果是顶层属性，则为 null
• property：KProperty<*> 类型的元数据对象，包含属性的名称、类型等信息

Kotlin 标准库还提供了两个接口来规范化这套约定：

// 只读属性的委托约定
interface ReadOnlyProperty<in T, out V> {
    operator fun getValue(thisRef: T, property: KProperty<*>): V
}

// 可变属性的委托约定
interface ReadWriteProperty<in T, V> {
    operator fun getValue(thisRef: T, property: KProperty<*>): V
    operator fun setValue(thisRef: T, property: KProperty<*>, value: V)
}

operator 关键字是必须的——它告诉编译器这些函数遵循操作符约定，可以被 by 语法调用。

编译器转换：属性委托在字节码中变成了什么

当你写下 var p: String by Delegate() 时，编译器执行以下转换：

// Kotlin 源码
class Example {
    var p: String by Delegate()
}

编译后的字节码（等效 Java）：

public final class Example {
    // ① 生成隐藏的 $delegate 字段，存储委托对象
    private final Delegate p$delegate = new Delegate();

    // ② 属性的 getter 被重写为调用委托的 getValue
    public final String getP() {
        return this.p$delegate.getValue(
            this,                              // thisRef：宿主对象
            $$delegatedProperties[0]           // KProperty 元数据
        );
    }

    // ③ 属性的 setter 被重写为调用委托的 setValue
    public final void setP(String value) {
        this.p$delegate.setValue(
            this,                              // thisRef
            $$delegatedProperties[0],          // KProperty 元数据
            value                              // 新值
        );
    }

    // ④ 编译器生成的静态元数据数组
    static final KProperty[] $$delegatedProperties = new KProperty[]{
        Reflection.mutableProperty1(
            new MutablePropertyReference1Impl(
                Example.class, "p", "getP()Ljava/lang/String;"
            )
        )
    };
}

整个过程可以用一张图来概括：

Kotlin 源码                          字节码产物
─────────                          ────────

var p: String by Delegate()   →   ① p$delegate 字段（存储 Delegate 实例）
                                  ② getP() → p$delegate.getValue(this, metadata)
                                  ③ setP() → p$delegate.setValue(this, metadata, value)
                                  ④ $$delegatedProperties 静态数组（KProperty 元数据）

关键技术细节：

1. $delegate 字段：编译器为每个委托属性生成一个命名为 属性名$delegate 的字段，类型是委托对象的实际类型
2. KProperty 元数据：编译器在类的静态初始化中生成 $$delegatedProperties 数组，存储所有委托属性的反射元数据。这些元数据在编译时生成，运行时不涉及反射查找
3. 无运行时开销：getValue / setValue 的调用解析在编译时完成，字节码中是直接的方法调用，没有反射

标准库内置委托深度解析

lazy：线程安全的延迟初始化

lazy 是最常用的标准库委托。它将属性的初始化推迟到第一次访问时，并且提供三种不同的线程安全策略。

val heavyObject: HeavyObject by lazy {
    println("初始化中...")
    HeavyObject()
}

三种线程安全模式的实现差异

lazy 函数的核心实现是一个工厂方法，根据 LazyThreadSafetyMode 参数分发到不同的实现类：

// Kotlin 标准库源码（简化）
public fun <T> lazy(
    mode: LazyThreadSafetyMode = LazyThreadSafetyMode.SYNCHRONIZED,
    initializer: () -> T
): Lazy<T> = when (mode) {
    LazyThreadSafetyMode.SYNCHRONIZED -> SynchronizedLazyImpl(initializer)
    LazyThreadSafetyMode.PUBLICATION  -> SafePublicationLazyImpl(initializer)
    LazyThreadSafetyMode.NONE         -> UnsafeLazyImpl(initializer)
}

SYNCHRONIZED：默认模式，双重检查锁

这是默认的线程安全模式。SynchronizedLazyImpl 使用经典的**双重检查锁（Double-Checked Locking）**模式来确保初始化 lambda 只被执行一次：

// SynchronizedLazyImpl 源码（简化）
private class SynchronizedLazyImpl<out T>(initializer: () -> T) : Lazy<T> {
    private var initializer: (() -> T)? = initializer
    @Volatile private var _value: Any? = UNINITIALIZED_VALUE  // 哨兵值
    private val lock = this  // 使用自身作为锁对象

    override val value: T
        get() {
            val v1 = _value
            // ① 第一次检查：无锁快速路径
            if (v1 !== UNINITIALIZED_VALUE) {
                @Suppress("UNCHECKED_CAST")
                return v1 as T
            }
            // ② 加锁
            return synchronized(lock) {
                val v2 = _value
                // ③ 第二次检查：防止重复初始化
                if (v2 !== UNINITIALIZED_VALUE) {
                    @Suppress("UNCHECKED_CAST")
                    v2 as T
                } else {
                    val typedValue = initializer!!()
                    _value = typedValue
                    initializer = null  // 释放 lambda 引用，避免内存泄漏
                    typedValue
                }
            }
        }
}

几个精妙的实现细节：

• @Volatile：确保 _value 的写入对其他线程立即可见，配合双重检查锁使用
• UNINITIALIZED_VALUE 哨兵：使用一个特殊的私有对象作为"未初始化"标记，而不是用 null——因为 null 可能是合法的初始化结果
• initializer = null：初始化完成后将 lambda 置空，释放它捕获的所有外部引用，防止内存泄漏
• lock = this：使用 Lazy 实例自身作为锁对象。这里有一个潜在风险——如果外部代码对同一个 Lazy 实例进行 synchronized，可能导致死锁

PUBLICATION：允许多线程同时初始化

SafePublicationLazyImpl 使用 AtomicReferenceFieldUpdater 来实现无锁的竞争式初始化：

// SafePublicationLazyImpl 源码（简化）
private class SafePublicationLazyImpl<out T>(initializer: () -> T) : Lazy<T> {
    @Volatile private var _value: Any? = UNINITIALIZED_VALUE

    override val value: T
        get() {
            val value = _value
            if (value !== UNINITIALIZED_VALUE) {
                @Suppress("UNCHECKED_CAST")
                return value as T
            }
            // 多个线程可能同时执行到这里
            val initValue = initializer!!()
            // CAS 操作：只有第一个完成的线程能成功设置值
            if (valueUpdater.compareAndSet(this, UNINITIALIZED_VALUE, initValue)) {
                return initValue
            }
            // 其他线程的初始化结果被丢弃，返回第一个线程设置的值
            @Suppress("UNCHECKED_CAST")
            return _value as T
        }
}

这种模式适用于初始化操作是幂等的（即多次执行结果相同）且你想避免锁开销的场景。

NONE：无锁，单线程专用

UnsafeLazyImpl 是最简单的实现——没有任何同步机制：

// UnsafeLazyImpl 源码（简化）
internal class UnsafeLazyImpl<out T>(initializer: () -> T) : Lazy<T> {
    private var initializer: (() -> T)? = initializer
    private var _value: Any? = UNINITIALIZED_VALUE

    override val value: T
        get() {
            if (_value === UNINITIALIZED_VALUE) {
                _value = initializer!!()
                initializer = null
            }
            @Suppress("UNCHECKED_CAST")
            return _value as T
        }
}

在 Android 开发中，如果你确定一个属性只在主线程访问（比如 View 相关的属性），使用 NONE 模式可以获得最佳性能。

三种模式的全景对比

用餐厅比喻这三种模式：SYNCHRONIZED 就像一道菜只能有一个厨师做——其他厨师必须等着，保证不会重复做菜，但等待时间可能较长。PUBLICATION 允许每个厨师都尝试做这道菜，但最终只有第一个做好的会端上桌，其余的直接倒掉。NONE 则假定厨房只有一个厨师，不需要任何协调，效率最高，但如果突然来了第二个厨师，可能会出事故。

lazy 在字节码中的表现

val data by lazy { loadData() } 编译后，本质上和属性委托的通用转换一致：

// 编译后等效 Java
private final Lazy data$delegate = LazyKt.lazy(() -> loadData());

public final Data getData() {
    return (Data) this.data$delegate.getValue();
}

这里 Lazy 接口本身实现了 getValue 操作符：

// Lazy 接口中的 getValue 扩展函数
public inline operator fun <T> Lazy<T>.getValue(
    thisRef: Any?, property: KProperty<*>
): T = value

因此 lazy 的 getValue 最终就是访问 Lazy.value 属性，整条调用链完全内联，运行时开销极低。

observable / vetoable：属性变更的发布 - 订阅机制

observable：变更后通知

Delegates.observable 在属性值发生变化之后触发回调：

import kotlin.properties.Delegates

class UserProfile {
    var name: String by Delegates.observable("未设置") { property, oldValue, newValue ->
        println("${property.name}: '$oldValue' → '$newValue'")
    }
}

val profile = UserProfile()
profile.name = "Alice"   // 输出: name: '未设置' → 'Alice'
profile.name = "Bob"     // 输出: name: 'Alice' → 'Bob'

vetoable：变更前审批

Delegates.vetoable 在属性值变化之前触发回调，回调返回 false 则拒绝赋值：

class Account {
    var balance: Int by Delegates.vetoable(0) { _, oldValue, newValue ->
        // 只允许余额增加，拒绝减少
        newValue >= oldValue
    }
}

val account = Account()
account.balance = 100     // 通过：0 → 100
println(account.balance)  // 100
account.balance = 50      // 被拒绝：100 → 50 不满足条件
println(account.balance)  // 仍然是 100

源码级解析：ObservableProperty 基类

observable 和 vetoable 都基于同一个基类 ObservableProperty。这是一个精巧的**模板方法模式（Template Method Pattern）**应用：

// kotlin.properties.ObservableProperty 源码
public abstract class ObservableProperty<V>(initialValue: V) : ReadWriteProperty<Any?, V> {
    private var value = initialValue

    // 钩子方法：赋值前调用，返回 false 则拒绝赋值
    protected open fun beforeChange(
        property: KProperty<*>, oldValue: V, newValue: V
    ): Boolean = true

    // 钩子方法：赋值后调用
    protected open fun afterChange(
        property: KProperty<*>, oldValue: V, newValue: V
    ): Unit {}

    // 核心模板方法
    override fun getValue(thisRef: Any?, property: KProperty<*>): V = value

    override fun setValue(thisRef: Any?, property: KProperty<*>, value: V) {
        val oldValue = this.value
        if (!beforeChange(property, oldValue, value)) {
            return  // beforeChange 返回 false，拒绝赋值
        }
        this.value = value
        afterChange(property, oldValue, value)
    }
}

然后 observable 和 vetoable 分别覆写不同的钩子方法：

// Delegates.observable —— 覆写 afterChange
public fun <T> observable(
    initialValue: T,
    onChange: (property: KProperty<*>, oldValue: T, newValue: T) -> Unit
): ReadWriteProperty<Any?, T> =
    object : ObservableProperty<T>(initialValue) {
        override fun afterChange(property: KProperty<*>, oldValue: T, newValue: T) {
            onChange(property, oldValue, newValue)
        }
    }

// Delegates.vetoable —— 覆写 beforeChange
public fun <T> vetoable(
    initialValue: T,
    onChange: (property: KProperty<*>, oldValue: T, newValue: T) -> Boolean
): ReadWriteProperty<Any?, T> =
    object : ObservableProperty<T>(initialValue) {
        override fun beforeChange(property: KProperty<*>, oldValue: T, newValue: T): Boolean {
            return onChange(property, oldValue, newValue)
        }
    }

这个设计是教科书级别的**开闭原则（OCP）**实践——ObservableProperty 对扩展开放（通过覆写钩子方法），对修改关闭（核心的 setValue 模板不需要改动）。

map 委托：将属性存储在 Map 中

Kotlin 标准库为 Map<String, *> 和 MutableMap<String, *> 提供了 getValue / setValue 扩展函数，使得你可以将属性的存储直接委托给一个 Map 对象。

class User(map: Map<String, Any?>) {
    val name: String by map
    val age: Int by map
}

// 属性名自动作为 Map 的键
val user = User(mapOf("name" to "Alice", "age" to 30))
println(user.name)  // Alice
println(user.age)   // 30

编译器的转换逻辑：

// user.name 编译后等效于：
public final String getName() {
    // 以属性名 "name" 为键，从 map 中取值
    return (String) MapsKt.getValue(this.map, null, $$delegatedProperties[0]);
}

标准库中 Map.getValue 的实现：

// kotlin.collections 中的扩展函数
@JvmName("getOrImplicitDefaultNullable")
public operator fun <V, V1 : V> Map<in String, @Exact V>.getValue(
    thisRef: Any?, property: KProperty<*>
): V1 {
    // 用属性名作为键获取值
    return getOrImplicitDefault(property.name) as V1
}

这个特性在以下场景中特别实用：

// ① JSON 解析——将 JSON 对象映射为 Kotlin 属性
fun parseUser(json: Map<String, Any?>): User = User(json)

// ② Android Bundle/Intent 参数解包
class UserFragment : Fragment() {
    private val args by lazy { requireArguments() }
    // Bundle 实现了 Map 接口，可以直接委托
    val userId: String by args
    val userName: String by args
}

对于可变属性，使用 MutableMap：

class MutableUser(map: MutableMap<String, Any?>) {
    var name: String by map   // 读写都通过 map
    var age: Int by map
}

val map = mutableMapOf<String, Any?>("name" to "Alice", "age" to 30)
val user = MutableUser(map)

user.name = "Bob"
println(map["name"])  // Bob ← 修改属性会同步修改底层 Map

自定义委托实战：SharedPreferences 委托

理解了属性委托的编译原理，我们可以构建一个实用的自定义委托——将属性的读写自动持久化到 SharedPreferences：

class PreferenceDelegate<T>(
    private val prefs: SharedPreferences,
    private val key: String,
    private val defaultValue: T
) : ReadWriteProperty<Any?, T> {

    @Suppress("UNCHECKED_CAST")
    override fun getValue(thisRef: Any?, property: KProperty<*>): T {
        return when (defaultValue) {
            is String  -> prefs.getString(key, defaultValue) as T
            is Int     -> prefs.getInt(key, defaultValue) as T
            is Boolean -> prefs.getBoolean(key, defaultValue) as T
            is Float   -> prefs.getFloat(key, defaultValue) as T
            is Long    -> prefs.getLong(key, defaultValue) as T
            else -> throw IllegalArgumentException("不支持的类型: ${defaultValue!!::class}")
        }
    }

    override fun setValue(thisRef: Any?, property: KProperty<*>, value: T) {
        prefs.edit().apply {
            when (value) {
                is String  -> putString(key, value)
                is Int     -> putInt(key, value)
                is Boolean -> putBoolean(key, value)
                is Float   -> putFloat(key, value)
                is Long    -> putLong(key, value)
                else -> throw IllegalArgumentException("不支持的类型: ${value!!::class}")
            }
            apply()  // 异步写入
        }
    }
}

// 工厂函数——让使用更简洁
fun <T> SharedPreferences.delegate(key: String, defaultValue: T) =
    PreferenceDelegate(this, key, defaultValue)

使用方式：

class AppSettings(prefs: SharedPreferences) {
    // 读写属性时自动读写 SharedPreferences
    var username: String by prefs.delegate("username", "")
    var darkMode: Boolean by prefs.delegate("dark_mode", false)
    var fontSize: Int by prefs.delegate("font_size", 14)
}

// 使用时完全透明——就像普通属性一样
val settings = AppSettings(context.getSharedPreferences("app", MODE_PRIVATE))
settings.username = "Alice"           // 自动写入 SharedPreferences
println(settings.username)            // 自动从 SharedPreferences 读取

这个委托的编译产物和前面分析的通用属性委托一致——username$delegate 字段存储 PreferenceDelegate 实例，getUsername() / setUsername() 委托给 getValue() / setValue()。

provideDelegate：在委托创建时进行校验

普通属性委托的局限

在前面的 SharedPreferences 委托中，我们手动传入了 key 参数。如果忘记传或传错了怎么办？你需要一种机制，在委托对象被创建的那一刻就进行校验。

provideDelegate 操作符

provideDelegate 让你在属性与委托对象绑定时介入：

class ValidatedPreferenceProvider(
    private val prefs: SharedPreferences,
    private val allowedKeys: Set<String>
) {
    // provideDelegate 在属性初始化时被调用
    operator fun provideDelegate(
        thisRef: Any?,
        property: KProperty<*>
    ): ReadWriteProperty<Any?, String> {
        // 在委托创建时校验属性名
        val key = property.name
        check(key in allowedKeys) {
            "属性 '$key' 不在允许的键列表中: $allowedKeys"
        }
        // 校验通过，返回实际的委托对象
        return PreferenceDelegate(prefs, key, "")
    }
}

class UserSettings(provider: ValidatedPreferenceProvider) {
    var username: String by provider   // ✅ 如果 "username" 在允许列表中
    var email: String by provider      // ✅ 如果 "email" 在允许列表中
    // var invalid: String by provider // ❌ 运行时抛出 IllegalStateException
}

编译器的处理

当存在 provideDelegate 时，编译器的转换逻辑略有不同：

// 无 provideDelegate 时
private final Delegate prop$delegate = new Delegate();

// 有 provideDelegate 时
private final ReadWriteProperty prop$delegate = 
    provider.provideDelegate(this, $$delegatedProperties[0]);
    //       ^^^^^^^^^^^^^^^^
    //   先调用 provideDelegate 获取实际的委托对象

整个流程如下：

属性初始化
    │
    ├─ 存在 provideDelegate？
    │   ├─ 是：调用 provideDelegate(thisRef, property)
    │   │       ├─ 执行校验逻辑
    │   │       ├─ 校验通过 → 返回实际委托对象 → 存储到 $delegate 字段
    │   │       └─ 校验失败 → 抛出异常
    │   └─ 否：直接将 by 后面的对象存储到 $delegate 字段
    │
    └─ 后续访问属性：$delegate.getValue() / setValue()

provideDelegate 的核心价值在于将运行时错误提前到对象初始化阶段。如果你的委托需要根据属性的名称、类型或注解来决定行为，provideDelegate 是校验这些条件的最佳位置。

字节码全景：委托机制的完整编译产物

让我们用一段综合性的代码来串联本文所有核心知识点：

// ① 类委托 + 选择性覆写
interface Logger {
    fun log(message: String)
    fun level(): String
}

class ConsoleLogger : Logger {
    override fun log(message: String) = println("[CONSOLE] $message")
    override fun level(): String = "DEBUG"
}

class TimestampLogger(logger: Logger) : Logger by logger {
    override fun log(message: String) {
        println("[${System.currentTimeMillis()}] $message")
    }
}

// ② 属性委托 + lazy + observable
class AppState {
    // lazy 委托：延迟初始化
    val config: Map<String, String> by lazy(LazyThreadSafetyMode.NONE) {
        loadConfig()
    }

    // observable 委托：变更通知
    var currentUser: String by Delegates.observable("guest") { prop, old, new ->
        println("${prop.name}: $old → $new")
    }

    // Map 委托
    val metadata: String by mapOf("metadata" to "v1.0")

    private fun loadConfig(): Map<String, String> = mapOf("env" to "prod")
}

编译产物清单：

设计哲学总结

纵观 Kotlin 委托机制的整套设计，可以提炼出三条核心认知：

1. 编译器是最忠实的"代码打字员"

无论是类委托的转发方法，还是属性委托的 $delegate 字段和 getter/setter 重写，编译器生成的代码与你手写的完全等价。零反射、零动态代理、零运行时开销——你获得的是更简洁的源码，付出的编译时间几乎可以忽略不计。

2. 组合是可组装的，继承是刚性的

类委托让你可以将多个接口的实现分别委托给不同的专业对象，像乐高积木一样组装功能。而继承只允许你从一个父类"继承"——一旦继承链确定，修改基类就可能波及所有子类。by 关键字把"组合优于继承"从工程建议变成了语言特性。

3. 属性委托是横切关注点的标准化解决方案

缓存（lazy）、变更通知（observable）、持久化（自定义委托）、校验（provideDelegate）——这些都是与业务逻辑正交的横切关注点。属性委托提供了一种标准化的方式来封装和复用这些关注点，让每个属性的声明都能明确表达"这个值怎么获取、怎么存储、怎么校验"，而不是把这些逻辑散落在 getter/setter 或 init 块中。

理解了委托在字节码层面的真实面貌——类委托的转发方法、属性委托的 $delegate 字段和元数据数组、lazy 的双重检查锁、observable 的模板方法——你就能在工程实践中精确判断：什么时候用继承，什么时候用类委托，什么时候用 lazy 的哪种模式，什么时候需要 provideDelegate 来前置校验。这正是从"会用 API"到"理解机制"的认知跃迁。