Kotlin/Native协程多线程开发遇InvalidMutabilityException求助

安全阿岳

2026-5-8

解决KMM开发中InvalidMutabilityException的痛点

嘿，我完全懂你这种困惑！KMM确实很香，但Kotlin/Native的线程和冻结机制一开始真的容易踩坑。咱们来好好拆解你的问题：

为什么会触发InvalidMutabilityException？

你遇到的问题核心是Kotlin/Native旧内存模型的冻结规则，再加上协程1.3.9-native-mt的行为共同导致的：
当你通过withContext(Dispatchers.Default)切换线程时，Kotlin/Native会递归冻结所有被跨线程传递的对象——包括这些对象引用的所有依赖。在你的场景里，objectWhichContainsNetworking是MainViewModel的属性，当你在后台线程块里调用它的方法时，整个MainViewModel会被递归冻结。而你ViewModel里有可修改的var（比如保存视图状态的变量），后续尝试修改这个被冻结的可变属性时，自然就抛出了InvalidMutabilityException。

你提到精简代码能运行，就是因为那段代码里没有可修改的var，冻结后没有修改操作，所以没触发异常。

是内存模型的锅还是协程的问题？

主要是旧版Kotlin/Native内存模型的限制：在Kotlin 1.4.x及之前的内存模型中，跨线程传递对象必须被冻结，而且冻结是不可逆的，会影响整个对象树。
协程1.3.9-native-mt是配合旧内存模型的多线程协程版本，它允许跨线程调度，但严格遵循冻结规则，所以当你在协程里跨上下文传递持有ViewModel引用的对象时，就会触发冻结逻辑。

可行的解决方案

1. 从根源避免ViewModel被冻结（最推荐）

要解决问题，最好的办法就是不让ViewModel被冻结。核心思路是不要让ViewModel的引用被传递到其他线程：

重构ObjectWhichContainsNetworking的逻辑，让它的fetchData()方法不依赖ViewModel的任何状态，只通过参数接收所需数据，变成纯函数：

class ObjectWhichContainsNetworking {
    suspend fun fetchData(requestParams: RequestParams): DataResult {
        // 这里只处理网络请求，不引用任何ViewModel相关的对象
    }
}

然后在ViewModel里调用时，只传递必要的参数，避免让fetchData()捕获ViewModel的引用：

private fun loadResults() {
    coroutineScope.launch {
        try {
            val result = withContext(Dispatchers.Default) {
                objectWhichContainsNetworking.fetchData(RequestParams(/* 仅传递请求所需参数 */))
            }
            // 更新UI状态
        } catch (e: Exception) {
            // 处理错误
        }
    }
}

这样后台线程块里只传递了请求参数，不会触及ViewModel的引用，自然不会触发冻结。

2. 用不可变状态+Flow替代可变var（你已经尝试的有效方案）

正如你在编辑2里提到的，把ViewModel里的可变var替换成Flow，用不可变的状态类来承载UI状态，这样即使ViewModel被冻结，因为没有修改可变属性的操作，也就不会抛出异常了。

关于iOS端收集Flow的问题，你用的转换思路很对——Kotlin原生Flow在iOS上不能直接收集，需要转换成iOS平台友好的形式。这里可以给你一个简化的通用扩展，方便在iOS端调用：

// 在common模块的mobileMain源集里添加
fun <T> Flow<T>.asPlatformFlow(): PlatformFlow<T> = PlatformFlow(this)

class PlatformFlow<T>(private val origin: Flow<T>) : Flow<T> by origin {
    fun collect(
        scope: CoroutineScope,
        onNext: (T) -> Unit,
        onError: (Throwable) -> Unit = {},
        onComplete: () -> Unit = {}
    ) {
        scope.launch {
            try {
                origin.collect { onNext(it) }
                onComplete()
            } catch (e: Throwable) {
                onError(e)
            }
        }
    }
}

这样iOS端就可以通过collect方法，用回调的方式处理Flow的事件了。

3. 升级到新的Kotlin内存模型（长远方案）

如果你能把Kotlin版本升级到1.5.0及以上，可以启用新的实验性内存模型，它彻底取消了强制冻结的规则，改用结构化并发和所有权来管理线程安全，从根源上解决这类冻结问题。启用方法很简单，在项目的gradle.properties里添加：

kotlin.mpp.enableGranularSourceSetsMetadata=true
kotlin.native.binary.memoryModel=experimental

不过要注意，新内存模型在早期版本可能有一些兼容性问题，需要确认你的依赖库是否支持。

总结

你用Flow替换可变var的方案已经能解决当前的异常问题，是个很实用的临时解决办法。如果想从根源上避免这类问题，推荐重构代码结构，不让ViewModel的引用被传递到后台线程。长远来看，升级到新的Kotlin内存模型是更彻底的解决方案。

内容的提问来源于stack exchange，提问作者enyciaa

Kotlin/Native协程多线程开发遇InvalidMutabilityException求助

为什么会触发InvalidMutabilityException？ #

是内存模型的锅还是协程的问题？ #

可行的解决方案 #

1. 从根源避免ViewModel被冻结（最推荐） #

2. 用不可变状态+Flow替代可变var（你已经尝试的有效方案） #

3. 升级到新的Kotlin内存模型（长远方案） #

总结 #