Jetpack Compose的声明式UI让界面构建变得直观，但真实应用必然涉及网络请求、数据库读取、动画、定时器等副作用操作。Compose没有让这些操作随意散落在组合函数中，而是提供了一套体系化的副作用API。LaunchedEffect和remember就是这套体系里经常被放在一起讨论的两个工具，可它们解决的问题维度并不相同。只有先弄清楚Compose的组合模型和副作用边界，才能理解为什么有的场景需要remember，有的场景必须使用LaunchedEffect，以及两者配合时如何避免状态丢失和协程泄漏。

组合函数可能会被系统反复调用，每次调用都称为一次重组。在重组过程中，函数体里的所有代码都会重新执行。如果直接把耗时操作或对象创建逻辑写在函数体中，就会导致重复执行、资源浪费，甚至产生不可预测的行为。Compose为此划分了组合阶段与副作用阶段：组合阶段负责计算UI描述，应当保持纯粹且无副作用；副作用阶段则负责处理那些会影响外部状态或依赖外部环境的操作。remember和LaunchedEffect正是分别服务于这两个阶段的典型API。

remember：组合阶段的记忆工具

remember的核心职责是在重组之间保留某个值，避免因为函数重新执行而丢失状态。它的工作方式简单直接：第一次组合时计算传入的lambda结果并缓存，后续重组时只要key没有变化，就直接返回缓存值，而不是重新计算。这意味着remember本身不触发任何异步操作，也不启动协程，它只是一个同步的缓存机制。例如在计数器的经典写法中，使用remember包裹mutableStateOf，就能保证多次重组后仍然操作同一个状态对象。

@Composable
fun Counter() {
    val count = remember { mutableStateOf(0) }
    Button(onClick = { count.value++ }) {
        Text("当前计数: ${count.value}")
    }
}

如果去掉remember，每次重组都会创建一个新的MutableState对象，点击按钮后UI看似更新，实际上新状态对象在下一次重组时又被丢弃，计数永远无法累加。这就是remember存在的意义。除了保存状态，remember还可以缓存Bitmap、数据库连接、正则表达式等创建成本较高的对象。不过要注意，remember只能保证在组合存续期间保留值，如果Activity重建或进程被系统杀死，所有remember缓存都会丢失。对于需要跨配置变更保留的数据，应该改用rememberSaveable，它会配合Bundle机制保存可序列化的值。

remember同样支持传入key参数。当key变化时，缓存失效并重新计算lambda。这个特性很适合监听某个外部变量变化后重建对象，但又不想引入协程的场景。例如根据用户ID创建不同的数据仓库实例，就可以写成remember(userId) { UserRepository(userId) }。然而，如果需求是key变化后执行异步请求或定时操作，单纯使用remember就不合适了，因为remember的lambda必须保持同步且不应产生副作用，这时就需要LaunchedEffect介入。

LaunchedEffect：绑定协程的副作用执行器

LaunchedEffect的主要作用是启动一个与组合生命周期绑定的协程。当LaunchedEffect进入组合时，它会立即启动协程执行代码块；当LaunchedEffect离开组合时，协程会被自动取消；当传入的key发生变化时，旧协程先被取消，再启动新的协程。这种取消与重启机制让LaunchedEffect非常适合处理需要跟随状态变化的异步任务，比如根据当前选中项加载详情、监听用户输入防抖、执行一次性初始化等。

@Composable
fun UserProfile(userId: String) {
    var user by remember { mutableStateOf<User?>(null) }
    LaunchedEffect(userId) {
        user = api.fetchUser(userId)
    }
    user?.let {
        Text("用户名: ${it.name}")
    } ?: Text("加载中...")
}

在上面的代码中，UserProfile组合函数进入屏幕后，LaunchedEffect会启动协程请求用户数据。如果userId发生变化，旧请求协程会被取消，新请求协程立即启动，这就避免了旧数据覆盖新数据的问题。如果组件被移除出组合树，协程同样会被取消，从而防止内存泄漏。与手动调用rememberCoroutineScope并管理Job相比，LaunchedEffect把取消逻辑交给了Compose运行时，代码更加安全简洁。

LaunchedEffect的key机制并不等同于普通的相等比较。Compose使用equals方法判断key是否变化，如果一个LaunchedEffect传入了多个key，只要任意一个key不相等，协程就会重启。常见的错误是把Unit作为key，即LaunchedEffect(Unit)，表示只在进入组合时执行一次。这确实能够实现一次性初始化，但如果初始化依赖某个可变状态，后续状态变化就不会触发重新执行。因此把正确的状态参数作为key传入，是使用LaunchedEffect的关键步骤。另外，LaunchedEffect内部默认在主线程上下文执行，如果涉及网络或磁盘操作，需要自行切换到Dispatchers.IO，否则可能阻塞UI线程。

组合使用的典型场景与避坑建议

在实际开发中，remember和LaunchedEffect经常需要同时出现，但分工明确。remember负责保存状态和对象引用，LaunchedEffect负责执行与生命周期相关的异步副作用。常见的配合模式是：用remember创建MutableState或资源句柄，再用LaunchedEffect监听这些状态并触发请求、动画或更新。例如一个搜索框，输入文本保存在remember状态中，LaunchedEffect监听输入文本并加入延迟防抖，最后请求搜索接口。

@Composable
fun SearchScreen() {
    var query by remember { mutableStateOf("") }
    var result by remember { mutableStateOf("") }
    LaunchedEffect(query) {
        if (query.isNotBlank()) {
            delay(300)
            result = searchApi.search(query)
        }
    }
    TextField(value = query, onValueChange = { query = it })
    Text("搜索结果: $result")
}

这个例子中，remember保存了query和result两个状态变量，LaunchedEffect监听query的变化。用户每输入一个字符，旧协程都会被取消并重新计时，只有停顿超过300毫秒才会真正发起搜索请求。如果没有LaunchedEffect的取消机制，而是直接在onValueChange里启动协程，就可能在快速输入时发出大量请求，并且旧请求返回后覆盖新结果。这种防抖场景能很好地体现LaunchedEffect在副作用控制上的价值。

另一个需要注意的点是，不要用remember去执行副作用。虽然可以在remember的lambda里启动协程或者修改外部变量，但这种做法破坏了组合阶段的纯度，容易引发难以追踪的行为。同样，也不应该在LaunchedEffect里做纯粹的同步缓存工作，因为它会占用协程资源。保持边界清晰，能够让Compose的预览、测试和状态恢复机制更加稳定。如果遇到需要在离开组合时释放资源的场景，还可以结合DisposableEffect，它专门处理清理逻辑，而LaunchedEffect只负责协程启动。

总结来说，remember解决的是“如何让值在重组后不丢失”的问题，LaunchedEffect解决的是“如何在正确时机执行并取消异步任务”的问题。两者不是替代关系，而是组合声明式UI中对立统一的两个侧面。理解它们的执行时机和key规则，能够帮助你写出更健壮、更易维护的Compose代码。