context parameters：2.4 转正的隐式依赖

问题长什么样

// 只有最底下这个函数真的需要 logger 和 tx
suspend fun syncOrder(
    repo: OrderRepo, user: User,
    logger: Logger, tx: Transaction, clock: Clock      // ← 三个「环境」参数
) {
    val order = repo.load(user.id, logger, tx)          // 往下传
    validate(order, logger, clock)                      // 往下传
    repo.save(order, logger, tx)                        // 往下传
}

三个「环境类」的依赖，污染了整条调用链的签名。而它们和函数的业务语义毫无关系 —— syncOrder 的本质是「同步一个订单」，不是「同步一个订单，顺便还需要一个日志器、一个事务和一个时钟」。

现有的三条出路，各有代价：

2.4 的解法

context(logger: Logger, tx: Transaction)
suspend fun syncOrder(repo: OrderRepo, user: User) {   // 签名干净了
    logger.info("syncing ${user.id}")                  // 直接用，不用传
    val order = repo.load(user.id)                     // 它也声明了 context，自动接力
    tx.commit()
}

// 调用方:只要作用域里「有」这些东西就行
with(logger) {
    with(transaction) {
        syncOrder(repo, user)      // ✓ 编译器自己把 context 传进去
    }
}

三个性质，每一个都重要：

• 它在签名里。和全局单例的根本区别 —— context(tx: Transaction) 明明白白写着「这个函数需要一个事务」。依赖是显式的，传递是隐式的，这正是我们想要的组合。
• 它是类型安全的。调用点的作用域里如果没有 Transaction，编译错误（不是运行时崩溃 —— 对比一下 DI 框架的运行时依赖图解析失败）。
• 可以有多个。扩展接收者只能有一个，context parameters 想要几个有几个。而且它不占用 this —— 一个函数可以同时是 String 的扩展函数并且需要 Logger 上下文。

什么时候该用它

判据只有一条：这个依赖是「环境」还是「输入」？

另一个绝妙的用法是把「能力」编进类型：

// 只有在事务里才能调用的函数 —— 编译器强制
context(tx: Transaction)
fun OrderRepo.save(order: Order) { ... }

repo.save(order)                    // ✗ 编译错误：作用域里没有 Transaction
transaction { repo.save(order) }    // ✓ 只有这样才行

「必须在事务里调用」这条规则，从文档里的一句话，变成了编译器的一条铁律。同样的模式可以用在：必须在主线程调用、必须持有某个权限、必须已登录 —— 把运行时的检查（和随之而来的运行时崩溃）搬到编译期。

它也是 Arrow Raise DSL 的地基

第 21 章会详讲 Arrow，但因果关系在这里：

context(raise: Raise<RegError>)      // 「这个函数可以抛出 RegError 类型的错误」
fun register(form: Form): User {
    val email = Email.of(form.email) ?: raise.raise(RegError.BadEmail)
    return repo.save(form.name, email)
}

「这个函数会失败，失败的类型是 RegError」—— 这个信息印在签名里，而成功路径的代码读起来仍然像普通的顺序代码（没有 .map、没有 .flatMap、没有一层层解包）。Arrow 用 context parameters 重建了「受检异常」，但这次是类型安全、可组合、且不强制的。

这也解释了为什么 Kotlin 团队会推进这个特性：它不只是「少传几个参数」的语法糖，它是一块能力载体（capability） 的地基，很多库都在等它。

// 旧（context receivers，已废弃）
context(Logger)
fun doWork() { info("x") }        // 靠类型隐式解析，没有名字可用

// 新（context parameters，2.4 转正）
context(logger: Logger)
fun doWork() { logger.info("x") } // 有名字，显式访问

它和 DI 框架是什么关系

会取代 Hilt 吗？不会，它们解决的是相邻但不同的问题。

实际用法是互补的：用 Hilt 把 Logger 注入到 ViewModel，然后在 ViewModel 内部用 with(logger) { ... } 把它开成一个上下文，让下面所有纯函数都能用 —— 而那些纯函数的签名保持干净，且完全可以脱离 Android 单测（测试时传一个假 Logger、假 Clock 进去就行）。

塑形炉最后一章：不可变。它不是洁癖 —— 在 Compose 里，它直接就是帧率。