系统的附带效应是指在可组合函数作用域之外发生的应用状态变化，这种变化会影响可组合函数的行为或外部环境。这种效应通常与状态管理、副作用处理等场景相关，是函数式编程中需要特别注意的设计问题。
一、核心定义
作用范围边界 可组合函数（如 `LaunchedEffect`、`rememberState` 等）通常在其作用域内管理状态，但有时需要触发作用域外的状态变化（如网络请求、定时任务等）。
副作用与状态修改
副作用是指函数执行后产生的非预期结果（如修改全局变量、触发网络请求等），而附带效应特指这些副作用发生在可组合函数作用域之外。
二、典型应用场景
LaunchedEffect
在可组合项的作用域内运行挂起函数，但函数内部可能触发网络请求或修改全局状态，这些操作会发生在作用域外。
```kotlin
LaunchedEffect(Unit) {
// 执行网络请求或修改全局状态
}
```
状态提升与组合
当需要在可组合函数外部更新状态时，需使用 `rememberState` 或 `derivedStateOf` 等 API，这些操作会引发作用域外的状态变化。
```kotlin
val state = rememberState(initialValue)
// 状态更新会触发重组，但实际修改在作用域外完成
```
传统项目集成
在使用传统 XML 布局与 Compose 集成时，状态变化可能涉及非 Compose 组件，需通过附带效应处理。
三、设计建议
明确副作用边界
使用 `Effect API`（如 `LaunchedEffect`）时，需确保副作用在预期作用域内完成，避免状态竞争或内存泄漏。
避免副作用滥用
尽量减少可组合项的附带效应，保持其无副作用特性，提升代码可预测性和可维护性。
组合函数设计
通过 `derivedStateOf` 等组合函数，将副作用封装在组合逻辑中，避免副作用直接修改外部状态。
四、示例对比
无附带效应： 直接在可组合函数内完成所有操作，状态变化仅影响函数内部。 有附带效应
通过理解附带效应，开发者可以更精准地控制状态变化范围，提升应用性能和可维护性。
