Jetpack Compose 中的 @Composable 函数、remember、MutableState 以及 LaunchedEffect 这些概念深受 React 启发，这套副作用机制让开发者不断面对无限循环、竞态条件以及清理遗漏等陷阱。 信号中的文章直指 Hooks 核心问题，理解其映射关系才能在真实项目中规避风险。

LaunchedEffect 与 useEffect 的映射暴露出副作用根本风险

Jetpack Compose 的 LaunchedEffect 对应 React 的 useEffect。两者都在组件渲染完成后执行副作用代码。LaunchedEffect 接收 key 参数，当 key 变化时重新启动协程；useEffect 则通过依赖数组决定是否重新执行回调。

这种映射关系把副作用的本质风险暴露出来。副作用本身不参与渲染，却能触发状态更新，从而引发新一轮渲染。Compose 通过 LaunchedEffect 的协程作用域和 remember 机制来管理生命周期，React 则依赖 useEffect 的清理函数和依赖数组。两者都要求开发者精确控制副作用的触发时机，否则就会出现难以预料的行为。

在实际项目中，这种对应关系让前端开发者转战移动端时能快速上手，但也把老问题带了过去。很多团队在用 Compose 重构 Android 应用时，发现以前在 React 中踩过的 useEffect 坑几乎原样复现。文章强调，只有先认清这种映射，才能有意识地去管理副作用，而不是把它们当成黑盒。

副作用的根本风险在于它打破了纯函数的假设。UI 声明式框架本该根据状态自动计算视图，但副作用引入了外部世界：网络请求、订阅事件、操作 DOM 或修改全局变量。这些操作如果处理不当，就会让框架的渲染假设失效。LaunchedEffect 和 useEffect 都是框架提供的“逃生口”，允许开发者在受控环境下执行这些操作，但逃生口本身也需要正确使用。

依赖数组配置错误直接引发无限渲染循环

依赖数组写错是 React 项目中最常见的副作用陷阱之一。假设一个组件需要根据 props.id 获取数据，如果把整个 props 对象放进 useEffect 的依赖数组，每次父组件渲染都会产生新对象，导致 useEffect 不断执行，组件陷入无限循环。

真实项目中，这种情况经常出现在列表页的筛选器组件上。开发者为了方便把 filter 对象直接作为依赖，结果每一次筛选条件变化都触发重新请求，同时请求回调又更新了 filter 状态，形成死循环。类似的问题在 Compose 中表现为 LaunchedEffect 的 key 总是变化，导致协程反复启动。

解决办法是只把真正需要监听的原始值放入依赖数组。对于对象和数组，要么使用 useMemo 稳定化，要么提取出具体字段。ESLint 的 react-hooks/exhaustive-deps 规则能帮助发现大部分遗漏，但它不是万能的，开发者仍需理解规则背后的逻辑。

另一个常见场景是使用 setState 时把 state 本身作为依赖。如果回调里读取了旧 state 却没有正确使用函数式更新形式，就会造成循环。项目中经常看到开发者在 useEffect 里写 setCount(count + 1)，却把 count 放进依赖数组，结果每次渲染都加一，直到浏览器崩溃。

异步操作中的竞态条件让旧响应覆盖最新状态

异步是副作用的另一大雷区。用户快速切换不同详情页时，前一个请求可能后于后一个请求返回，导致旧数据覆盖了最新数据。这种竞态条件在 React 和 Compose 项目中都普遍存在。

典型场景是商品详情页。用户点开 iPhone 15 详情，随后立刻点开 iPhone 16。如果网络延迟不同，iPhone 15 的请求可能晚到，组件状态就被错误地更新为旧商品信息。文章提到的副作用陷阱在这里体现得淋漓尽致。

解决竞态条件的常用手段有两种。一是使用 AbortController 在新请求发起时取消旧请求，二是记录请求的 id，只处理最新一次的响应。React 18 的 useTransition 也能在一定程度上缓解，但核心逻辑仍需开发者自己把控。

在 Compose 中，LaunchedEffect 结合 rememberCoroutineScope 可以更方便地管理协程取消。关键在于把副作用的生命周期和组件状态的生命周期对齐，避免过期的副作用继续影响当前 UI。

清理函数缺失造成内存泄漏和订阅持续运行

忘记返回清理函数是另一个高频错误。useEffect 里订阅 WebSocket、添加事件监听器、设置定时器后，如果不在清理函数中取消订阅，这些操作就会一直运行。即使组件已经卸载，回调仍在执行，可能导致内存泄漏或意外的状态更新。

真实项目中，这种问题常出现在仪表盘实时数据组件里。组件卸载后，WebSocket 连接没有断开，后续组件重新挂载时又创建了新连接，页面同时存在多个相同订阅，数据重复推送，性能急剧下降。

最佳实践是始终为 useEffect 返回清理函数。清理函数会在组件卸载或依赖变化前执行，用于取消订阅、清除定时器、关闭连接。Compose 中的 DisposableEffect 提供了类似的机制，进一步强化了这种实践。

清理函数本身也可能有副作用，因此框架会保证清理函数的执行顺序。开发者需要确保清理操作是幂等的，即使多次执行也不会出错。

自定义 Hooks 封装能系统性减少重复陷阱

把重复的副作用逻辑抽成自定义 Hook 是减少陷阱的最有效方式之一。useFetch、useWebSocket、useLocalStorage 等自定义 Hook 把依赖管理、清理逻辑、竞态处理封装在内，业务组件只需调用即可。

对中文开发者来说，这意味着团队可以建立自己的 Hook 库，把经过验证的最佳实践固化下来。新人加入时不再需要从零学习每个副作用的注意事项，直接使用封装好的 Hook 就能大幅降低出错概率。

一个好的自定义 Hook 应该满足几个条件：依赖数组完整、清理函数完备、支持取消、提供 loading 和 error 状态。封装后，业务代码变得更声明式，也更容易测试。

许多开源库如 swr、react-query 正是通过强大的自定义 Hook 解决了数据获取领域的副作用问题。团队可以参考它们的实现，在项目中建立类似的基础设施。

调试工具链帮助快速定位 Hooks 副作用根源

React DevTools 的 Profiler 面板能清晰展示每个 useEffect 的执行时机和依赖变化。开发者可以录制一段操作，然后查看哪些 effect 在不该执行的时候执行了，从而快速定位问题。

Chrome 的 Performance 面板结合 React DevTools 可以看到渲染和副作用执行的完整时间线。特别适合分析无限循环这类导致卡顿的问题。Compose 项目则可以使用 Android Studio 的 Layout Inspector 和 Compose 专用的调试工具。

实际调试时，一个有效技巧是给每个 useEffect 的回调函数加上唯一名称或 console.log，带上当前依赖值。这样当循环发生时，控制台输出能清楚显示是哪个 effect、哪些依赖发生了变化。

另一个实用方法是在严格模式下运行应用。React 会故意在开发环境双重调用 effect，帮助提前暴露清理函数缺失和非幂等的问题。很多团队在上线前都会打开严格模式跑一遍核心流程，提前发现隐藏的副作用 bug。

通过这些工具和方法，开发者可以把副作用从黑盒变成可观测、可调试的对象，从而在真实项目中系统性地提升代码质量。

参考来源