题干与适用场景
你的 Kotlin 服务有一组调用链都会使用同一个 UserService、日志器或事务上下文。团队希望减少重复传参，但不想把依赖藏进全局变量，也需要逐步从 context receivers 迁移到 Kotlin 2.2 的 context parameters。请说明语义、调用方式、歧义处理和适用边界。目标岗位是 Kotlin/JVM 工程师；本题讨论语言特性，不假设特定 DI 框架。
面试官考察点
强回答会指出 context parameter 是编译期可见的隐式依赖，不是运行时容器。解析发生在调用点，按类型寻找当前作用域的值；同层存在多个兼容值会产生歧义。候选人还应区分 context receiver 与 context parameter 的命名和迁移差异，承认该特性仍有限制，说明普通参数更适合公开 API 或高可读性边界。
回答前需要澄清的问题
- 依赖是否跨越公共模块或库 API？若是，显式参数通常更容易发现、测试和跨语言调用。
- 依赖是否在一段局部 DSL 或事务操作中稳定不变？若是，context parameter 可以减少样板传递。
- 同一作用域是否可能有两个同类型实现？若是，必须设计命名、显式传入或包装类型来消除歧义。
- 项目是否已经使用 context receivers？若是，先确认编译器选项和迁移范围，不能把两者混在同一模块中。
30 秒回答框架
“Context parameter 把依赖声明在函数签名上，但由调用点作用域提供。编译器按类型解析；同层有多个匹配值就报歧义。它适合局部 DSL、事务或日志上下文，能减少重复传参；公共 API、跨语言边界或依赖经常变化时，我仍用显式参数。迁移时启用对应编译器选项，检查旧 receiver 的调用和类级场景，因为两者并非一一对应。”
分步骤深入解答
先声明依赖，再在作用域内提供它：
interface UserService {
fun findUser(id: Int): String
}
context(users: UserService)
fun greeting(id: Int): String = "Hello ${users.findUser(id)}"
fun main() {
val service = object : UserService {
override fun findUser(id: Int) = "user-$id"
}
context(service) {
println(greeting(7))
}
}函数签名仍然声明了依赖，因此调用者能看到它；调用点的 context(service) 负责提供值。解析按类型匹配当前作用域，不按变量名优先。若同一层同时有 serviceA 与 serviceB，调用会失败，而不是静默选择一个实现。可以在调用处显式传入命名 context argument，或用不同的包装类型表达不同语义。
它与普通参数的边界取决于信息密度。局部 DSL 中十几个函数都需要同一个不可变上下文时，context parameter 能避免每层重复传递；单个函数只用一次依赖时，普通参数更直白。公共库 API 还要考虑 Java 调用、IDE 可发现性和文档生成，隐式来源越远，维护成本越高。
context receivers 的迁移不能只做关键词替换。JetBrains 的迁移说明指出，context parameters 需要命名，类上的 context receiver 没有直接对应物；同一模块不能同时启用两种模式。项目应先按模块切换编译器参数，再逐个检查调用点、可调用引用和类级 receiver。官方文档还列出限制：构造函数不能声明 context parameters，带 context 的属性不能有 backing field 或 initializer。
可以用匿名参数减少未使用变量，但它仍参与解析：
context(_: UserService)
fun logGreeting(id: Int) {
println(greeting(id))
}选择规则是“局部且稳定的共享上下文用 context；跨边界、需要显式替换或可能多实现的依赖用普通参数或显式 DI”。不要把 context parameter 当成全局服务定位器；依赖仍需在测试中由调用作用域提供，生命周期也仍由外层对象管理。
高质量示范回答
Context parameter 是编译期的隐式依赖声明。函数会把 UserService 写进签名，但调用者在一个 context(service) 作用域中提供实例；编译器按类型从当前作用域寻找，若同层有两个匹配值就报歧义。我会在局部 DSL、事务或日志链路中使用它，因为这些函数共享一个稳定上下文；对公共 API、Java 互操作或需要频繁替换的依赖，继续使用显式参数或 DI。迁移 context receivers 时，我会先切换模块编译选项，再检查命名、可调用引用和类级 receiver，并接受构造函数与带 backing field 属性等限制。
常见错误
- 错误表现 → 说 context parameter 是运行时依赖注入容器 → 失败原因是解析由编译器在调用点完成 → 修正方法是解释作用域、类型匹配与编译期歧义。
- 错误表现 → 认为同类型实例会按变量名自动选择 → 失败原因是同层多匹配值会直接报歧义 → 修正方法是显式 context argument 或使用语义包装类型。
- 错误表现 → 把 context receiver 直接改名为 context parameter → 失败原因是命名要求、类级场景和可调用引用存在差异 → 修正方法是按模块迁移并逐个检查调用点。
- 错误表现 → 所有依赖都改成隐式 → 失败原因是公共边界的依赖可发现性下降 → 修正方法是把 context 限定在局部稳定上下文，边界处使用普通参数。
追问及应对
追问一：测试函数时如何替换 context 依赖？
在测试中创建 fake 或 stub，实现同一接口，再用 context(fake) { ... } 执行被测函数。若测试需要频繁切换多个实现，显式参数通常更清楚，也更容易在测试报告中看到依赖。
追问二：两个同类型服务都必须存在怎么办？
为接口增加语义包装类型，例如 PrimaryUserService 与 AuditUserService，或在调用点使用显式 context argument。不要依赖声明顺序，因为解析规则不会把顺序当作优先级。
追问三：为什么不把 context parameter 放进构造函数？
当前 Kotlin 文档明确限制构造函数不能声明 context parameters。需要对象级依赖时，使用普通构造参数或显式工厂；把它强行改成全局上下文会隐藏生命周期和线程边界。