Jetpack Compose类型安全导航：为何不能在Composable体中调用navigate？

核心原因很简单：Composable函数体的职责是根据状态描述UI，而导航属于会改变应用状态的「副作用」，不能直接放在UI构建的核心流程里。具体拆解成这几点：

1. 重组会导致重复触发导航，引发卡顿甚至无限循环 #

Composable会在状态变化时反复执行重组。如果你在函数体里直接写navController.navigate(Screen.Auth)，每次state.logoutRequired相关的状态变化触发重组，导航就会被调用一次——哪怕你已经跳转到Auth页面，HomeScreen可能还会因为其他状态波动继续重组，导致多次触发导航请求，自然会出现丢帧、卡顿。

而LaunchedEffect是带「触发键」的副作用容器，只有当你传入的键（比如state.logoutRequired）发生变化时，它才会执行一次内部逻辑。用它包裹导航后，只会在logoutRequired从false变成true时触发一次导航，完美避免了重复调用的问题。

2. Composable函数体的执行时机不适合做导航 #

Composable函数是在UI线程的「UI构建阶段」执行的，此时正在生成当前页面的UI树。直接在这里执行导航，会立刻触发新页面的重组，相当于打断了当前页面的UI绘制流程——当前页面还没画完就被强制跳转，必然导致视觉上的卡顿、丢帧。

而onClick、onDismiss这类回调是用户交互触发的，此时当前页面的UI已经绘制完成，执行导航不会干扰现有UI的渲染；LaunchedEffect则是在UI构建完成后，在后台协程里执行逻辑，既不会阻塞UI线程，也不会打断当前的UI构建流程。

3. 这是Compose的设计原则：UI与副作用分离 #

Compose的核心逻辑是「状态驱动UI」，Composable函数体只负责描述“当前状态下UI应该长什么样”，所有涉及状态变更、外部操作的副作用（比如导航、网络请求、数据库读写），都应该放在专门的副作用API（LaunchedEffect、rememberCoroutineScope等）或者用户交互回调里。

这种分离能让UI渲染更稳定、可预测，也让代码逻辑更清晰——UI描述和业务操作互不干扰。

你之前遇到的卡顿，本质就是把副作用逻辑混在了UI描述里，违反了Compose的设计规范。换成LaunchedEffect后，既符合规范，也解决了性能问题。

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