distinct().size 或 toSet().size 这样的间接写法。Kotlin 2.4.20 带来了一组语义清晰的集合校验函数，让代码意图一目了然。
在 Kotlin 2.4.20 之前，检查集合元素是否全部唯一，最常见的写法是：
val ids = listOf("user_001", "user_002", "user_003")
// 检查是否有重复
val allUnique = ids.distinct().size == ids.size
// 或者
val noDuplicates = ids.toSet().size == ids.size
这些写法能工作，但有几个问题：
distinct() 会创建一个全新的 List，toSet() 会创建一个 Set，仅仅是为了比较大小data class User(val id: String, val email: String, val name: String)
val users = listOf(
User("1", "alice@example.com", "Alice"),
User("2", "bob@example.com", "Bob"),
User("3", "charlie@example.com", "Charlie")
)
// 检查邮箱是否唯一——旧写法
val emailsUnique = users.map { it.email }.distinct().size == users.map { it.email }.size
// 这行代码太长了，而且 map 执行了两次
检查所有元素是否相同也不优雅：
val statuses = listOf("active", "active", "active")
// 检查是否全部相同——旧写法
val allSame = statuses.toSet().size == 1
// 或者
val allSame2 = statuses.all { it == statuses.first() }
// 空集合时 first() 会抛异常，需要额外处理
Kotlin 2.4.20 引入了四个实验性函数：
| 函数 | 作用 | 返回 |
|---|---|---|
allDistinct() | 集合中所有元素是否互不相同 | Boolean |
allDistinctBy(selector) | 按指定属性判断元素是否互不相同 | Boolean |
allEqual() | 集合中所有元素是否完全相同 | Boolean |
allEqualBy(selector) | 按指定属性判断元素是否完全相同 | Boolean |
这些函数适用于 Collection、Sequence 和 Array，使用结构相等（equals）进行比较。
@OptIn(ExperimentalStdlibApi::class)
fun main() {
val ids = listOf("user_001", "user_002", "user_003")
println(ids.allDistinct()) // true
val withDuplicate = listOf("A", "B", "A")
println(withDuplicate.allDistinct()) // false
// 空集合返回 true（vacuous truth）
println(emptyList<String>().allDistinct()) // true
// 单元素集合也返回 true
println(listOf(42).allDistinct()) // true
}
这是最实用的函数之一——直接按对象的某个属性判断唯一性，无需先 map 再 distinct：
@OptIn(ExperimentalStdlibApi::class)
data class User(val id: String, val email: String, val name: String)
fun main() {
val users = listOf(
User("1", "alice@example.com", "Alice"),
User("2", "bob@example.com", "Bob"),
User("3", "charlie@example.com", "Charlie")
)
// 检查邮箱是否唯一
println(users.allDistinctBy { it.email }) // true
// 检查名字是否唯一
println(users.allDistinctBy { it.name }) // true
// 如果有重复邮箱
val usersWithDup = users + User("4", "alice@example.com", "Alice2")
println(usersWithDup.allDistinctBy { it.email }) // false
}
当你需要验证一批数据是否"整齐划一"时，这两个函数就派上用场了：
@OptIn(ExperimentalStdlibApi::class)
fun main() {
// 所有配置项相同
val configs = listOf("production", "production", "production")
println(configs.allEqual()) // true
val mixed = listOf("dev", "production", "staging")
println(mixed.allEqual()) // false
// 按属性检查一致性
data class Task(val id: Int, val status: String)
val tasks = listOf(
Task(1, "pending"),
Task(2, "pending"),
Task(3, "pending")
)
println(tasks.allEqualBy { it.status }) // true
}
这些新函数不仅仅是语法糖。与 distinct().size == size 不同，它们在发现第一个违规元素时就会立即返回，无需遍历整个集合：
// 旧写法：必须遍历全部元素，创建完整 Set
val hasNoDuplicates = largeList.toSet().size == largeList.size
// 新写法：遇到第一个重复就返回 false
val hasNoDuplicates = largeList.allDistinct()
对于大集合，尤其是重复元素出现在前部的场景，性能差异显著。allEqual() 同理——只要发现一个不同于首元素的值，就立即返回 false。
@OptIn(ExperimentalStdlibApi::class)
fun validateOrder(order: Order): Result<Order> {
if (!order.items.allDistinctBy { it.productId }) {
return Result.failure(IllegalArgumentException("订单包含重复商品"))
}
if (order.items.allEqualBy { it.quantity } && order.items.first().quantity == 0) {
return Result.failure(IllegalArgumentException("所有商品数量为零"))
}
return Result.success(order)
}
@OptIn(ExperimentalStdlibApi::class)
@Test
fun `generated IDs should be unique`() {
val ids = (1..1000).map { generateUniqueId() }
assertTrue(ids.allDistinct(), "生成的 ID 存在重复")
}
@Test
fun `all tasks should have same priority after batch update`() {
service.batchUpdatePriority(taskIds, Priority.HIGH)
val tasks = service.getTasks(taskIds)
assertTrue(tasks.allEqualBy { it.priority })
}
@OptIn(ExperimentalStdlibApi::class)
data class Response(
val participantId: String,
val answer: String,
val responseDate: String
)
fun analyzeSurvey(responses: List<Response>) {
// 检查是否有重复提交
if (!responses.allDistinctBy { it.participantId }) {
println("警告：存在同一参与者的多次提交")
}
// 检查是否所有人答案一致
if (responses.allEqualBy { it.answer }) {
println("所有参与者给出了相同答案")
}
// 检查是否都在同一天提交
if (responses.allEqualBy { it.responseDate }) {
println("所有回答在同一天提交")
}
}
@OptIn(ExperimentalStdlibApi::class)
fun checkLargeDataset() {
// Sequence 的惰性求值 + allDistinct 的短路求值 = 高效组合
val hasDuplicates = File("data.txt")
.useLines { lines ->
lines.map { it.trim() }
.filter { it.isNotEmpty() }
.allDistinct().not()
}
}
这些函数目前是实验性的，需要添加 opt-in 注解：
// 方式一：文件级注解
@file:OptIn(ExperimentalStdlibApi::class)
package com.example
// 方式二：函数级注解
@OptIn(ExperimentalStdlibApi::class)
fun myFunction() {
val result = myList.allDistinct()
}
或者在 build.gradle.kts 中全局启用：
kotlin {
compilerOptions {
optIn.add("kotlin.ExperimentalStdlibApi")
}
}
| 需求 | 旧写法 | 新写法 |
|---|---|---|
| 元素是否唯一 | list.distinct().size == list.size | list.allDistinct() |
| 按属性唯一 | list.map { it.id }.toSet().size == list.size | list.allDistinctBy { it.id } |
| 元素是否相同 | list.toSet().size == 1 | list.allEqual() |
| 按属性相同 | list.map { it.status }.toSet().size == 1 | list.allEqualBy { it.status } |
| 获取重复元素 | list.groupingBy { it }.eachCount().filter { it.value > 1 } | 仍需手动实现 |
注意：新函数只返回 Boolean。如果你需要知道哪些元素重复了，仍然需要 groupingBy 等方案。但对于"是否合法"的校验场景，新 API 已经足够。
Kotlin 2.4.20 的集合校验函数看似简单，却解决了日常开发中一个高频痛点。它们用语义化的命名替代了需要"翻译"的间接写法，用短路求值替代了无意义的全量遍历，用一个函数调用替代了冗长的链式操作。
如果你的项目已经升级到 Kotlin 2.4.20+，不妨搜索一下代码中的 distinct().size 和 toSet().size，把它们替换成更优雅的新写法。
如果你写过 Android 应用，这段代码一定不陌生：
class LocationViewModel {
private val _city = MutableStateFlow("")
val city: StateFlow<String> get() = _city
fun updateCity(newCity: String) {
_city.value = newCity
}
}
为了对外暴露只读的 StateFlow，同时在内部保持可变性，我们不得不声明两个属性：一个私有的 _city 用于存储实际状态，一个公开的 city 通过 getter 暴露。这种 underscore 模式 在 Kotlin 项目中无处不在——搜索记录、缓存列表、用户偏好……每个需要"内变外不变"的场景都要写一遍。
更糟糕的是，当属性增多时，类中会充斥着大量 _ 前缀的私有属性，代码可读性急剧下降：
class UserPreferences {
private val _theme = MutableStateFlow(Theme.LIGHT)
val theme: StateFlow<Theme> get() = _theme
private val _fontSize = MutableStateFlow(14)
val fontSize: StateFlow<Int> get() = _fontSize
private val _recentSearches = mutableListOf<String>()
val recentSearches: List<String> get() = _recentSearches.toList()
// 还有更多...
}
field 关键字Kotlin 2.3.0 允许你直接在属性声明中显式指定幕后字段，用一个属性替代原来的两个：
class LocationViewModel {
val city: StateFlow<String>
field = MutableStateFlow("")
fun updateCity(newCity: String) {
city.value = newCity // 直接通过属性名访问幕后字段
}
}
这里的 field = MutableStateFlow("") 声明了一个真正存储在类中的字段，但它对外表现为 val city: StateFlow<String>——只读。类内部可以直接通过 city 访问和修改这个字段，外部调用者只能看到不可变的 StateFlow。
来看 UserPreferences 的简化版本：
class UserPreferences {
val theme: StateFlow<Theme>
field = MutableStateFlow(Theme.LIGHT)
val fontSize: StateFlow<Int>
field = MutableStateFlow(14)
val recentSearches: List<String>
field = mutableListOf()
fun addSearch(query: String) {
recentSearches.add(query)
if (recentSearches.size > 10) {
recentSearches.removeAt(0)
}
}
}
// 使用
val prefs = UserPreferences()
prefs.addSearch("Kotlin")
println(prefs.recentSearches) // [Kotlin]
// prefs.recentSearches.add("Flow") // 编译错误！外部无法修改
三个属性，三种封装需求，代码量减少近一半。
显式幕后字段最强大的地方在于可以和自定义访问器无缝配合。考虑一个带验证逻辑的属性：
class UserProfile {
var name: String = ""
set(value) {
field = value.trim()
}
var age: Int = 0
set(value) {
field = value.coerceAtLeast(0)
}
}
这里的 field 是传统的隐式幕后字段引用（Kotlin 1.0 就有的特性）。而显式幕后字段的不同之处在于，你可以指定字段的类型和初始值，甚至让字段类型与属性声明类型不同：
class CachedApiClient {
// 属性对外是 String?，幕后字段是 MutableStateFlow<String?>
val username: StateFlow<String?>
field = MutableStateFlow(null)
// 带自定义 getter 的缓存属性
var cachedData: Map<String, Any>
field = emptyMap()
get() {
if (field.isEmpty()) {
field = loadFromDisk()
}
return field
}
private set
}
显式幕后字段的一个隐藏优势是 Smart Cast 可以正常工作。在旧的双属性模式中，这是一个常见的痛点：
// 旧模式：Smart Cast 经常失败
class OldViewModel {
private val _user = MutableStateFlow<User?>(null)
val user: StateFlow<User?> get() = _user
}
fun greet(vm: OldViewModel) {
val u = vm.user.value
if (u != null) {
println(u.name) // OK，但需要局部变量
}
// vm.user.value.name // 不行！Smart Cast 无法跨越 getter 调用
}
// 新模式：Smart Cast 直接可用
class NewViewModel {
val user: StateFlow<User?>
field = MutableStateFlow(null)
}
fun greet(vm: NewViewModel) {
// 在类内部直接访问 field 时，Smart Cast 正常工作
}
显式幕后字段在 Kotlin 2.3.0 中作为实验性特性引入，需要添加编译器参数：
// build.gradle.kts
kotlin {
compilerOptions {
freeCompilerArgs.add("-Xexplicit-backing-fields")
}
}
<!-- pom.xml (Maven) -->
<plugin>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-maven-plugin</artifactId>
<configuration>
<args>
<arg>-Xexplicit-backing-fields</arg>
</args>
</configuration>
</plugin>
在 KotlinConf'26 主题演讲中，JetBrains 宣布该特性正在走向稳定。如果你使用的是 Kotlin 2.4.x，可以关注后续版本中移除实验性标记的进展。
显式幕后字段并非万能。以下场景不能使用：
// ❌ val 属性没有 setter，field 不可变
val computed: Int
field = 0 // 无法在后续修改
// ❌ lateinit 属性不支持
lateinit var lazy: String
field = "" // 编译错误
// ❌ 委托属性不支持
var delegated: String by lazy { "hello" }
field = "" // 编译错误，field 被委托对象接管
// ❌ 接口属性没有幕后字段
interface Config {
val timeout: Long
field = 3000L // 编译错误
}
记住一条原则：只有带自定义 getter 或 setter 的 var 属性才能使用显式幕后字段。
通过 Tools → Kotlin → Show Kotlin Bytecode → Decompile 查看字节码，显式幕后字段编译后与手写双属性模式完全一致——都是 private 字段加 getter。没有反射，没有额外对象分配，运行时开销为零。
显式幕后字段解决了 Kotlin 中一个长期存在的样板代码问题。它不是新概念的发明，而是对已有 field 关键字的自然延伸——从"隐式引用"到"显式声明"，让属性的封装意图更加清晰。对于大量使用 StateFlow、缓存、惰性加载的 Kotlin 项目，这是一个立竿见影的代码简化工具。
你的项目中有多少对 _xxx / xxx 属性？是时候给它们"瘦身"了。
先看一段看似无害的代码：
data class User(val username: String, val email: String)
fun processUser(user: User) {
val (email, username) = user
println("用户 $username 的邮箱是 $email")
}
fun main() {
processUser(User("alice", "alice@example.com"))
// 输出：用户 alice 的邮箱是 alice@example.com
// 等等……这不对！
}
发现问题了吗？val (email, username) = user 中，email 实际拿到的是 username 的值（"alice"），而 username 拿到的是 email 的值（"alice@example.com"）。
因为两个属性都是 String 类型，编译器不会报任何错误。这个 Bug 在生产环境中可能悄悄存在很久。
更可怕的是，如果同事重构了 User 类，调整了属性顺序：
// 重构前
data class User(val username: String, val email: String)
// 重构后
data class User(val email: String, val username: String)
项目中所有使用位置解构的代码都会静默地交换值，没有任何编译警告。
Kotlin 2.3.20 引入了基于名称的解构声明。变量不再按 component1()、component2() 的位置绑定，而是按属性名匹配：
data class User(val username: String, val email: String)
fun main() {
val user = User("alice", "alice@example.com")
// 显式形式：val 变量名 = 属性名
(val mail = email, val name = username) = user
println(name) // alice
println(mail) // alice@example.com
}
注意语法要点：
val(val name = username, val mail = email) 效果完全相同email 提取后叫 mail这个特性通过 -Xname-based-destructuring 编译器参数控制，支持三种模式：
only-syntax（推荐入门）只启用显式的按名称解构语法，不改变现有圆括号解构的行为：
// build.gradle.kts
kotlin {
compilerOptions {
freeCompilerArgs.add("-Xname-based-destructuring=only-syntax")
}
}
val user = User("alice", "alice@example.com")
// 传统写法依然按位置（向后兼容）
val (first, second) = user // first = username, second = email
// 新写法按名称
(val name = username, val mail = email) = user
name-mismatch（渐进迁移）在 only-syntax 的基础上，如果位置解构时变量名和属性名对不上，编译器会给出 warning：
val (email, username) = user
// Warning: Variable 'email' name does not match property name 'username'
这非常适合在现有项目中做渐进式迁移——先开启 warning，逐步修复不匹配的解构，再考虑切换到更激进的模式。
complete（面向未来）连传统的 val (a, b) 也会按名称匹配，而按位置解构改用方括号语法：
// 按名称（默认行为变了！）
val (email, username) = user // 自动按名称匹配
// 按位置（新语法）
val [first, second] = user // 按 componentN() 顺序
这个模式最具颠覆性，适合新项目或已完成迁移的项目。
命名解构不仅适用于普通的 val 声明，还能在 for 循环和 Lambda 参数中使用：
data class Person(val name: String, val surname: String, val age: Int)
val people = listOf(
Person("John", "Doe", 30),
Person("Jane", "Bar", 25)
)
// for 循环中按名称解构
for ((val surname, val name) in people) {
println("Surname: $surname, Name: $name")
}
// Lambda 参数中按名称解构
people.forEach { (val name, val surname) ->
println("Name: $name, Surname: $surname")
}
传统的解构依赖 component1()、component2() 等 operator 函数，而命名解构直接按属性名匹配，这意味着普通类（非 data class）也能享受解构的便利：
class Config(
val host: String,
val port: Int,
val timeout: Long
)
fun main() {
val config = Config("localhost", 8080, 3000L)
// 不需要 componentN()，直接按属性名解构
(val server = host, val p = port) = config
println("连接 $server:$p")
}
对于已有项目，建议分三步走：
only-syntax 模式，新代码使用显式命名解构name-mismatch，利用 warning 定位现有代码中的潜在问题complete 模式（需同时引入方括号按位置解构）// 迁移示例
// Before（容易出错）
val (email, username) = user
// After（安全、清晰）
(val email, val username) = user // 显式命名解构
Kotlin 的命名解构是一个迟到但实用的特性。它解决了长期以来 data class 解构中"顺序即正确"的脆弱性，让重构更安全，让代码意图更清晰。虽然目前仍是实验性特性，但已经值得在新代码中尝试。
你遇到过因解构顺序导致的 Bug 吗？欢迎在评论区分享你的经历。
]]>在 kotlinx.coroutines 中，当异常跨越协程边界时，框架会创建新的异常实例来保留原始上下文。这个过程中，自定义异常的属性（如错误码、行号等）往往会丢失：
// 旧行为：自定义属性在堆栈恢复时丢失
class FileProcessException(
val lineNumber: Int,
val filePath: String,
cause: Throwable? = null
) : RuntimeException("处理文件 $filePath 第 $lineNumber 行时出错", cause)
suspend fun processFile(path: String) {
// 模拟在第 42 行出错
throw FileProcessException(42, path, NumberFormatException("无效的数字格式"))
}
suspend fun main() {
try {
coroutineScope {
async { processFile("/data/config.txt") }
}
} catch (e: FileProcessException) {
// 问题：e.lineNumber 可能变成默认值 0
// e.filePath 可能变成 null
println("出错行号: ${e.lineNumber}") // 输出 0，而不是 42！
}
}
这是因为 kotlinx.coroutines 在恢复堆栈时，通过反射创建新的异常实例，但无法正确传递自定义构造参数。结果就是：你看到了堆栈，但丢失了关键的业务上下文。
Kotlin 2.4.20 在标准库中引入了 StackTraceRecoverable 接口，让自定义异常能够控制如何在堆栈恢复时复制自身：
@OptIn(ExperimentalStdlibCoroutineSupportApi::class)
class FileProcessException(
val lineNumber: Int,
val filePath: String,
cause: Throwable? = null
) : RuntimeException("处理文件 $filePath 第 $lineNumber 行时出错", cause),
StackTraceRecoverable<FileProcessException> {
// 关键：告诉框架如何正确复制这个异常
override fun copyForStackTraceRecovery(): FileProcessException =
FileProcessException(lineNumber, filePath, this)
}
实现这个接口后，当 kotlinx.coroutines 需要创建新的异常实例时，会调用 copyForStackTraceRecovery() 方法，确保所有自定义属性都被正确保留。
让我们看一个更完整的实际场景：
@OptIn(ExperimentalStdlibCoroutineSupportApi::class)
data class ApiErrorContext(
val endpoint: String,
val userId: String,
val requestId: String,
val timestamp: Long = System.currentTimeMillis()
)
@OptIn(ExperimentalStdlibCoroutineSupportApi::class)
class ApiException(
val statusCode: Int,
val context: ApiErrorContext,
cause: Throwable? = null
) : RuntimeException(
"API 请求失败 [${context.endpoint}] 状态码: $statusCode, " +
"用户: ${context.userId}, 请求ID: ${context.requestId}",
cause
), StackTraceRecoverable<ApiException> {
override fun copyForStackTraceRecovery(): ApiException =
ApiException(statusCode, context, this)
}
// 使用场景
suspend fun fetchUserData(userId: String): UserData {
val requestId = generateRequestId()
val context = ApiErrorContext(
endpoint = "/api/users/$userId",
userId = userId,
requestId = requestId
)
return try {
httpClient.get(context.endpoint) {
header("X-Request-ID", requestId)
}.body()
} catch (e: ClientRequestException) {
throw ApiException(e.response.status.value, context, e)
}
}
suspend fun main() {
coroutineScope {
val deferred = async {
fetchUserData("user_12345")
}
try {
deferred.await()
} catch (e: ApiException) {
// 现在所有属性都完整保留！
println("错误上下文:")
println(" 端点: ${e.context.endpoint}")
println(" 用户: ${e.context.userId}")
println(" 请求ID: ${e.context.requestId}")
println(" 时间戳: ${e.context.timestamp}")
println(" 状态码: ${e.statusCode}")
// 堆栈跟踪也完整保留了原始位置
e.printStackTrace()
}
}
}
这个特性目前是实验性的，需要两个步骤来启用：
// build.gradle.kts
kotlin {
compilerOptions {
freeCompilerArgs.add("-Xstack-trace-recovery")
}
}
@OptIn(ExperimentalStdlibCoroutineSupportApi::class)
class MyCustomException(...) : StackTraceRecoverable<MyCustomException> {
override fun copyForStackTraceRecovery(): MyCustomException = ...
}
确保使用兼容的版本：
dependencies {
implementation("org.jetbrains.kotlin:kotlin-stdlib:2.4.20")
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0+")
}
如果你的项目中有自定义异常类，并且会在协程中抛出，建议都实现 StackTraceRecoverable：
// 通用模板
@OptIn(ExperimentalStdlibCoroutineSupportApi::class)
class BusinessException(
val errorCode: String,
val userMessage: String,
val details: Map<String, Any>,
cause: Throwable? = null
) : RuntimeException(userMessage, cause),
StackTraceRecoverable<BusinessException> {
override fun copyForStackTraceRecovery() =
BusinessException(errorCode, userMessage, details, this)
}
copyForStackTraceRecovery() 应该只做简单的属性复制，不要包含复杂的业务逻辑：
// ✅ 好的做法：简单复制
override fun copyForStackTraceRecovery() =
MyException(field1, field2, this)
// ❌ 避免：复杂逻辑
override fun copyForStackTraceRecovery(): MyException {
val processed = complexProcessing(field1) // 不要这样做
return MyException(processed, field2, this)
}
复制时应该将当前实例作为新实例的 cause，这样能保留完整的异常链：
override fun copyForStackTraceRecovery() =
MyException(importantData, this) // this 作为 cause
堆栈跟踪恢复会带来一定的性能开销，但只在异常发生时才会触发。在正常执行路径上，几乎没有额外成本：
堆栈跟踪恢复可以与 Kotlin 的协程调试工具配合使用：
// 启用协程调试模式
System.setProperty("kotlinx.coroutines.debug", "on")
// 在异常日志中同时输出：
// 1. 完整的堆栈跟踪（包含协程名称）
// 2. 自定义的业务上下文
// 3. 协程的创建和恢复位置
Kotlin 2.4.20 的堆栈跟踪恢复机制解决了协程调试中的一个长期痛点。通过实现简单的 StackTraceRecoverable 接口，你的自定义异常就能在异步边界保持完整的上下文信息。
关键要点：
StackTraceRecoverable 接口可以解决这个问题虽然这个特性目前还是实验性的，但它的设计已经相当成熟。如果你的项目重度依赖协程，现在就可以开始试用，让异步代码的调试变得更加轻松。
]]>参考资料：
在 Kotlin 中，companion object 一直是定义类级别常量、工厂方法和工具函数的标准方式。但它有几个痛点：
// 旧写法：需要 @JvmStatic 才能让 Java 方便调用
class Vector(val x: Double, val y: Double) {
companion object {
@JvmStatic
val ZERO = Vector(0.0, 0.0)
@JvmStatic
fun fromPolar(r: Double, theta: Double): Vector =
Vector(r * kotlin.math.cos(theta), r * kotlin.math.sin(theta))
}
}
每个 @JvmStatic 注解都是一份"税"——忘记写一个，Java 端就要多写一层 Companion 访问。而且 companion object 本质上是一个对象实例，JVM 上会额外生成一个类。
Kotlin 2.5.0 引入了 companion {} 块语法，直接生成 静态成员，不再创建对象实例：
// 新写法：companion 块，编译为 JVM 静态成员
class Vector(val x: Double, val y: Double) {
companion {
val ZERO = Vector(0.0, 0.0)
fun fromPolar(r: Double, theta: Double): Vector =
Vector(r * kotlin.math.cos(theta), r * kotlin.math.sin(theta))
}
}
关键区别：
@JvmStatic：在 JVM 平台上，companion 块中的成员自动编译为静态方法和字段companion object 会生成一个单例类，而 companion 块不会object 关键字，语义更明确Java 端可以直接调用：
// Java 代码中直接调用，无需 .Companion
Vector v = Vector.fromPolar(1.0, Math.PI / 4);
Vector zero = Vector.ZERO;
更强大的能力是 伴生扩展。即使一个类没有定义 companion object，你也能通过伴生扩展为它添加类级别成员。这对 Java 类型尤其有用：
// 为 Java 的 LocalDate 添加伴生扩展
package com.example.dates
import java.time.LocalDate
companion fun LocalDate.fromCompact(text: String): LocalDate {
require(text.length == 8) { "格式应为 YYYYMMDD，共 8 位" }
return LocalDate.of(
text.substring(0, 4).toInt(),
text.substring(4, 6).toInt(),
text.substring(6, 8).toInt(),
)
}
使用时只需导入：
import com.example.dates.fromCompact
import java.time.LocalDate
val date = LocalDate.fromCompact("20261013") // 2026-10-13
LocalDate 是 Java 类，根本没有 Kotlin 的 companion object，但伴生扩展让我们像使用原生 Kotlin API 一样调用它。
伴生扩展属性也同样好用：
// 伴生扩展属性，支持 backing field
companion val Vector.UnitX get() = Vector(1.0, 0.0)
companion val Vector.UnitY get() = Vector(0.0, 1.0)
这个特性目前还是实验性的，需要手动开启。
Gradle Kotlin DSL：
kotlin {
compilerOptions {
// 只启用伴生块
freeCompilerArgs.add("-Xcompanion-blocks")
// 同时启用伴生扩展（会生成 pre-release 编译产物）
freeCompilerArgs.add("-Xcompanion-blocks-and-extensions")
}
}
注意事项：
-Xcompanion-blocks）不影响编译产物的稳定性-Xcompanion-blocks-and-extensions）会生成 pre-release binaries，作为库发布时需注意下游兼容性companion {} 会提示你启用该特性| 特性 | companion object | companion 块 | 伴生扩展 |
|---|---|---|---|
| 需要声明在类内部 | 是 | 是 | 否（顶层声明） |
| 生成额外类 | 是 | 否 | 否 |
| JVM 静态成员 | 需 @JvmStatic | 自动 | 自动 |
| 可扩展 Java 类型 | 否 | 否 | 是 |
| 可实现接口 | 是 | 否 | 否 |
| 有实例 | 是（单例） | 否 | 否 |
| 属性支持 backing field | 是 | 是 | 是 |
不需要急着把所有 companion object 替换掉。以下场景建议优先迁移：
@JvmStatic，减少出错可能以下场景暂时保留 companion object：
伴生块和伴生扩展是 Kotlin 语言在"简洁"和"实用"方向上的又一次进化。它解决了 companion object 长期存在的 JVM 互操作痛点，同时通过伴生扩展打开了为任意类型（包括 Java 类型）添加类级别成员的大门。
虽然目前还是实验性特性，但设计已经相当成熟（KEEP-0449），预计在未来版本中会逐步稳定。建议大家现在就开始在项目中试用，提前感受 Kotlin 语言演进的节奏。
// 一句话总结
companion { /* 更简洁的类级别成员 */ }
companion fun Type.newMember() { /* 给任意类型加成员 */ }
]]>参考资料：
这个网站将承载社区的全部公开内容：
当然，网站本身并不是 Kotlin 写的，但作为 Kotlin 社区，我们随时欢迎用 Kotlin 相关的工具链来建设社区设施。如果你有兴趣参与网站建设，欢迎在仓库提 issue 或 PR。
欢迎重庆及西南地区的朋友们关注与加入！
fun main() {
println("Hello, CQKUG!")
}