Kotlin 集合分三组：List、Set、Map，每组各有"只读"与"可变"两个版本，共六个类型。这一设计看着啰嗦，实际上是用类型承载意图——函数签名里出现 List 就是承诺"不修改你的数据"。但只读与可变的关系有个非常反直觉的细节：List 不等于不可变，它可能只是一个可变实现的可读视图。这个细节是本篇的核心，也是实际项目里最容易出错的地方。
先把结论放在前面：六个类型是 List/MutableList、Set/MutableSet、Map/MutableMap。List 与 MutableList 的关系是继承（MutableList : List），而 listOf() 创建的只读列表在 JVM 上底层就是 java.util.Arrays$ArrayList 或 SingletonList（单元素时）——它是不可变的实现，不存在"只读视图指向可变实现"的问题。真正需要警惕视图语义的是 asList()（Java 侧只读视图）与 .toMutableList()。只读类型保证的是"通过这个引用改不了"，不是"底层数据不可变"。
机制拆解
先厘清三个维度。结构维度：List 有序可重复，Set 无序唯一，Map 是键值对。可见性维度：只读接口只暴露查询方法，可变接口额外暴露 add/remove/put/clear。实现维度：Kotlin 的 listOf 走 Arrays.asList 或单元素优化，可变版本走 ArrayList；setOf 走 LinkedHashSet（保持插入顺序），mapOf 走 LinkedHashMap。mutableSetOf 默认是 LinkedHashSet 而不是 HashSet——这个默认值的差异会影响输出顺序，做过 JSON 序列化或对比测试的人都遇到过。
视图语义是第二个关键点。Kotlin 里有两个操作会得到"活视图"：
java.util.List通过扩展asList()转成 KotlinList——这是真正的视图，底层 Java 集合被改，视图跟着变。val m = mutableMapOf(...); val view: Map = m——这里 Kotlin 的类型系统保证了view不能调用put，但如果m本身之后被修改，view读到的内容也会变（因为它们指向同一个对象）。
反过来，toList()/toMap() 是真拷贝。这个区别决定了逃逸分析的结论：如果函数内部持有 mutableList 并对外返回 List，返回的是同一个对象（内部后续修改会影响调用方）；如果返回 toList()，则彻底隔离。
这些坑的正确绕法
最常见的坑是把 mutableListOf 直接暴露给外部，只读声明形同虚设。 表现有两种：①用 val list = mutableListOf<String>() 存数据，函数返回 List<String>，但因为该类型实际是 MutableList，调用方强转或通过 Java 接口拿到后能改；②更常见的是数据缓存——模块 A 维护一个 MutableList 缓存，通过只读类型返回给模块 B，B 侧改动（或 A 侧后续的清理逻辑与 B 侧持有的引用不一致）导致数据错乱。修法：内部可变、对外只读——用私有字段持有 MutableList，对外方法返回 List（且返回 toList() 拷贝，或者明确接受"只读视图"的语义并在注释里写清）。
其次是以为 listOf 返回的列表是 ArrayList 视图，做逃逸分析时结论错误。 表现是分析内存占用时以为"只读列表和可变列表一样占内存"，或者反过来以为 listOf 结果是共享的。实际上 listOf 的实现是真不可变的（内部数组不对外暴露），所以它可以被安全地跨线程共享、不需要防御性拷贝——这与 Java 的 Arrays.asList 完全不同（后者是视图，可变且是固定长度）。Kotlin 语境下的正确结论是：listOf 的结果没有视图风险；需要拷贝的只有 asList() 视图与 toMutableList()。
还有一个更隐蔽的坑：mutableSetOf/mutableMapOf 默认保持插入顺序，不是哈希顺序。 表现是 Java 那边用 HashSet 输出的顺序与 Kotlin 侧不同，导致接口对比、快照测试、签名算法（把集合拼成字符串做 hash）结果不一致。根因是 Kotlin 标准库选择 LinkedHashSet/LinkedHashMap 作为默认实现，为了可预测性。修法：需要哈希语义时显式 HashSet()/HashMap()；反过来，需要稳定顺序时明确写 toList()/keys.toList() 再排序，不要依赖默认顺序。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 1) 内部可变、对外只读：正确的封装形态
class CartRepo {
private val items = mutableListOf<Item>() // 私有持有，可变
private val cache = mutableMapOf<String, Item>() // 私有持有，可变
fun snapshot(): List<Item> = items.toList() // 拷贝：外部改动不影响内部
fun names(): Set<String> = items.map {
it.name }.toSet() // 只读类型
fun lookup(id: String): Item? = cache[id] // Map 取值天然可空
fun add(item: Item) {
items.add(item); cache[item.id] = item } // 唯一修改入口
}
// 2) 只读 ≠ 不可变：asList() 是活视图
val backing = mutableListOf("a")
val view: List<String> = backing.asList() // Kotlin 扩展：包一层
backing.add("b")
Log.d("t", "view=$view") // [a, b] 跟着变
val copy = backing.toList() // 独立副本
backing.add("c")
Log.d("t", "copy=$copy") // [a, b] 不变
// 3) listOf 是真不可变，可安全跨线程共享
val immutable = listOf("a", "b") // 无需防御性拷贝
// val bad = listOf("a").toMutableList() // 想要可变请显式转
// 4) 默认实现是 LinkedHash，不是 Hash
val s1 = mutableSetOf(3, 1, 2) // 输出顺序 3,1,2（插入序）
val s2 = hashSetOf(3, 1, 2) // 显式哈希，顺序不保证
val m1 = mutableMapOf("b" to 1, "a" to 2) // LinkedHashMap，b 在前
// 5) 遍历形式：只读接口有多种消费方式
fun use(list: List<Item>) {
list.forEach {
} // 只有元素
list.forEachIndexed {
i, v -> } // 需要下标
val idx = list.indexOfFirst {
it.valid } // 找位置
val sum = list.sumOf {
it.price } // 聚合
val grouped = list.groupBy {
it.category } // 分组
}
// 6) 与 Java 互操作
val javaList: java.util.List<Item> = list.toJavaList() // 拷贝出的可变视图
val ktList: List<Item> = javaList.toList() // 只读拷贝
这段代码值得盯三处：第一处，CartRepo 演示了"私有可变字段 + 对外只读方法 + toList() 拷贝"，这是本篇最该抄走的形态；第二处，第 2 段把 asList() 视图与 toList() 拷贝的差别用日志演示出来，一眼能看出区别；第三处，第 4 段指出默认实现是 LinkedHash，需要哈希语义时要显式 hashSetOf。
这题在面试里怎么问、怎么答
"只读集合和不可变集合有什么区别？"答：只读是类型层面的约束（没有修改方法），不可变是实现层面的保证（数据本身改不了）。Kotlin 的 List 是只读的，但它的实现可能是 MutableList（视图），也可能是真不可变的 listOf 结果。listOf 的结果既只读又不可变，所以可以共享；asList() 的结果只读但可被外部改动，所以要当心。
"为什么 Kotlin 不像 Java 那样只有一种集合类型？"答：Java 用接口 + 可变语义统一表达，代价是"能不能改"无法从签名看出来；Kotlin 把修改能力做进类型，好处是编译期就能阻止误改，且只读接口可以对应到 Java 的只读用法（不产生额外的适配）。代价是要记六个类型名，以及要注意"只读不等于不可变"这条缝隙。
"Set 怎么保证唯一？用的是哪种相等？"答：靠 equals 与 hashCode 契约。放入 hashSet 的对象若这两个方法没成对实现，可能出现"加了两份看起来一样的"或"删不掉"（mutableSetOf("a").also { it.remove(it.first()) } 之类）。这与 data class 的坑同源——数组字段的 equals 是引用比较。
"使用中遇到过什么问题？"案例一：模块 A 暴露 List 但实际是可变缓存，模块 B 排序后污染了 A 的数据；修复为返回 toList()。案例二：签名算法把集合拼串做 hash，Kotlin 侧与 Java 侧结果不一致导致验签失败；定位到 Kotlin 默认 LinkedHashSet 保持插入序而 Java 用了 HashSet；修复为双方都显式排序后再拼串。
再补一个工程上值得讲清的一点：Android 上的集合选型有一条实用经验——优先用 Kotlin 标准库的类型，写 Java 侧 API 时再转换。 理由是 Kotlin 类型携带意图（MutableList 一眼看出会改），而转换成本很低（toMutableList()/toJavaList()）。但有两条例外：①Compose 的 LazyColumn 需要稳定 key，key 传 item.id 而不是索引，索引在列表变动时会错位；②大数据集避免频繁 toList()，因为每次都是 O(n) 拷贝，实时搜索框这类高频路径应该用 SnapshotStateList 或 mutableStateListOf 直接持有可变集合并配合 Snapshot.withMutableSnapshot 批量更新，避免"每次输入都拷贝一次全量"的写法。
给正在准备面试的你
把两套体系画成一张"三行六列"的表：行是 List/Set/Map，列是"只读"与"可变"。每个格子填上只读接口名、对应可变类型、常用工厂函数（listOf/mutableListOf 等）与底层实现（Arrays$ArrayList/ArrayList/LinkedHashSet/LinkedHashMap）。表格右侧再画一个"视图与拷贝"的小对照：asList() → 活视图（箭头指回原集合），toList() → 拷贝（独立箭头）。图下方写一条纪律："内部可变、对外只读，跨边界 toList()。"这张图就是这题的完整答案。
再补工程案例与踩坑——应用落点是把项目里所有对外返回集合的方法过一遍，内部字段是 Mutable* 就把返回改成 toList() 或明确注释"只读视图"；把依赖 HashSet/HashMap 无序语义的地方（签名、快照测试）改成显式 hashSetOf 或排序后使用；Compose 列表的 key 从索引换成业务 id。
复习时别孤立刷题：when 表达式——只读集合的消费方式（forEach/forEachIndexed/聚合）本质是 when 之外的数据流写法，与 when 一起构成 Kotlin 的分支与集合语法。
划两句重点：只读是类型约束、不可变是实现保证；listOf 真不可变可安全共享，asList() 是活视图需拷贝；mutableSetOf/mutableMapOf 默认 LinkedHash 保序，要哈希语义显式 hashSetOf；对外返回集合用 toList() 隔离。
下一篇聊集合操作符链：filter、map 与 fold——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：when-表达式：比-switch-强在哪里
下一篇预告：集合操作符链：filter、map-与-fold
有任何问题欢迎在评论区留言交流。
