忽略使用Jetpack Compose Effect Handlers可能带来哪些后果？

如果你直接在Composable函数里写副作用代码（比如网络请求、协程启动、资源注册），完全不用官方的Effect Handlers，会碰到这些实打实的问题：

• 无意义重复执行，资源严重浪费
  Compose的重组机制会在组件状态变化、父组件刷新、系统配置变更（比如屏幕旋转）时重新执行Composable代码。要是你直接把网络请求、协程启动写在Composable根节点，每次重组都会触发一遍——比如屏幕转个向就多发起一次网络请求，轻则造成服务器压力、流量浪费，重则因为并发请求返回的数据顺序不一致，导致UI显示错乱。

• 内存泄漏，资源无法自动回收
  像广播接收器、WebSocket连接、Camera这类需要手动销毁的资源，如果不用DisposableEffect这类Handler绑定Composable生命周期，当组件从界面上消失时，这些资源不会被自动清理。比如你在详情页注册了一个电量广播，退出页面后接收器还在后台运行，不仅占内存，还可能在收到广播时尝试更新已经销毁的UI，直接引发崩溃。

• 协程“野跑”，生命周期完全失控
  直接在Composable里用CoroutineScope启动协程，而不用LaunchedEffect或rememberCoroutineScope，当组件被销毁时，协程不会自动取消。比如用户在商品页启动一个协程下载高清图，刚点返回键回到列表页，这个协程还在后台继续下载，既浪费流量，后续下载完成后还可能因为试图更新已销毁的组件，抛出空指针异常。

• 状态与UI不同步，业务逻辑混乱
  很多副作用需要依赖特定参数变化或者组件生命周期触发——比如切换Tab时重新加载对应数据，组件首次显示时初始化状态。不用带key的LaunchedEffect，你没法精准控制这些操作的执行时机：要么每次重组都重复执行，要么参数变化时不执行，导致UI显示的永远是旧数据，或者频繁刷新造成卡顿。

• 破坏Composable纯函数特性，陷入调试地狱
  Compose设计的核心是纯函数：相同输入对应相同输出，无副作用。直接写副作用代码会打破这个原则，让组件行为变得不可预测——你永远不知道哪次重组会触发副作用，排查bug时要逐一排查所有可能触发重组的State，调试难度直接拉满。

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