Compose Navigation 时序图深度拆解：背栈、生命周期与状态恢复全解析

最近在把团队里一个跑了三年的 Fragment 老项目整体切到 Jetpack Compose，别的都还好，唯独导航这块争议最大。有人说直接用原生 Navigation-Compose 就行，有人说要自己封装状态机，也有人说干脆用单一 Activity + 自行管理页面状态。最后我们选了官方 Navigation-Compose，并且在做技术方案评审的时候，我画了一套 Compose Navigation 的时序图。画完之后，原来争吵最凶的几个问题全都不争了，因为图一摆出来，谁先在哪个时间点触发重组、背栈生命周期的先后顺序、状态恢复的时机，一目了然。

说实话，大多数人对 Compose Navigation 的使用停留在"会调用 navigate()"的层面，但真到了页面被回收重建、状态被恢复错乱、生命周期回调乱跳的时候，没几个人能说清楚内部到底按什么顺序发生了什么。这篇文章我不打算写成官方文档的翻译版，而是用"时序图"这个视角，把 Compose Navigation 从启动到跳转、回退、状态恢复的完整链路拆给你看，每个关键节点卡在哪儿、为什么卡在哪儿、出问题怎么排查，全聊透。适合已经在用 Compose 写业务、但还想深入理解导航机制的中高级 Android 开发者。

1. 为什么要用"时序图"拆解 Compose Navigation

1.1 从"调用函数"到"时间轴上的协作"

大多数人在写 Compose Navigation 代码时，脑子里其实只有一条线：我点了按钮，调用了 navController.navigate("detail")，然后 Compose 界面就换了。这个认知在简单场景下完全够用，但一旦涉及多背栈、嵌套导航、参数恢复、进程重建，你就会发现"调用函数"这个心智模型根本解释不了问题。

时序图的本质，是把参与协作的各个对象拿出来，然后把消息在它们之间传递的先后顺序画在一条时间轴上。比如一次 navigate() 调用，它不是"一个函数执行完就结束"的事，而是 NavController、NavHost、BackStackEntry、Compose 重组机制、生命周期状态管理等多个角色之间的一系列消息传递。每一个角色什么时候入场、什么时候退出、谁先收到消息，直接决定了你屏幕上看到的状态。

我画这套时序图之后，团队里一个刚接触 Compose 三个月的同学都能准确说出"为什么 popBackStack 之后 rememberSaveable 里的数据还在"，因为时序图上就画着呢。这个收益不是读十遍源码能比的。

1.2 时序图的核心元素：参与者、消息、生命周期

在一个标准的导航时序图里，你至少要看懂三样东西。

参与者（Actor）是消息的发出者和接收者。在 Compose Navigation 里，最核心的参与者一般是这几个：调用导航的外部对象（通常是你某个 Screen 或者 ViewModel）、NavController、NavHost（它是 Composable 层面真正消费 NavController 状态的入口）、BackStackEntry（对应背栈里一个目的地实例）、以及目的地 Composable 本身。

消息是参与者之间的调用和事件，在时序图里通常用带箭头的线段表示。注意这里要区分"直接调用"和"异步回调"两类消息。比如 navigate() 是外部对象直接调用 NavController 的；而导航完成后 NavHost 内部产生的重组调度，并不是 NavController 主动调用了某个 Screen，而是通过以 Compose state 作为载体的隐式事件流完成的。这个差异如果不清，容易陷入"为什么我 navigate() 之后马上读某个状态读不到"的困惑。

生命周期在时序图上是另一条重要的横向维度。Compose Navigation 的每个 BackStackEntry 都带一个 LifecycleOwner，而且这个 LifecycleOwner 的状态是跟着导航事件"延迟"变化的，不是同步到位的。画图的时候，把 Lifecycle 状态变化的时刻单独划出来，你就能看到很多问题的本质。比如说，A 页面在 navigate 到 B 页面后，A 的 Lifecycle 不会立刻变成 STOPPED，而是等 B 页面进入 STARTED 之后才切过去。这个"交错切换"的节奏，在时序图上是一目了然的。

1.3 读图之前必须搞懂的 3 个核心对象

NavController 是导航的"中央调度器"。它维护着当前背栈、当前目的地的状态、导航事件的处理逻辑。每次 navigate() 调用，本质上都是在往 NavController 内部的 backStack 数据结构上做状态变更。

NavHost 是 Compose UI 层面对 NavController 的"渲染适配器"。它观察 NavController 暴露的当前导航状态，然后把对应的 Composable 内容组合到界面上。你可以把 NavHost 理解成"背栈状态与屏幕内容之间的接力棒"。

BackStackEntry 是背栈里的一个"目的地快照"。它不光记录你配置的 route，还承载着一个独立的 SaveableStateHolder 和 LifecycleRegistry。之所以说它是快照而不是单纯的"页面名称"，是因为每往 navigate() 一次，哪怕用同一个 route，生成的都是一个新的 BackStackEntry 实例。这个特性画到时序图里，就是两条几乎相同但时间点不一样的"生命线"。

2. Compose Navigation 整体架构与方案选型

2.1 为什么导航层值得单独设计

很多从传统 View 体系切过来的人，第一反应是"导航不就是一个状态变量 + when(变量) 切界面吗"。理论上确实可以，一个小 Demo 三五个页面，用 when 分支手动切换完全没毛病。但在真实的商业 App 里，导航承载的事情远比"切页面"多得多：页面要支持返回键、要支持进程被杀后的状态恢复、要支持深层链接直达某个页面、要支持底部 Tab 各自维护一套独立栈、要在切换过程中保留每个页面的滚动位置和输入状态。

这些需求如果全部自己造轮子，成本极高，而且容易造出半成品。Navigation-Compose 的价值在于，它把"导航这个业务动作"抽象成了一套标准的背栈模型，并且深度集成了 Compose 的声明式 UI 和生命周期体系。你不再需要手动维护"当前页面是哪个"这样的命令式状态，只需要声明"有哪几个目的地、彼此怎么连接"，Navigation-Compose 会基于背栈推算出当前应该渲染什么。

2.2 与传统 Fragment Navigation 对比

我这边实际做过一个双端对比实验：同一个模块，一套用 Fragment + Navigation 组件，一套用 Compose + Navigation-Compose，从开发效率、状态恢复、代码量三个维度都做了记录。结果比我想象的还要悬殊。

功能维度对比表：

这里需要特别说一点，Navigation-Compose 并不是"Fragment Navigation 的 Compose 版"，我们在迁移中就发现，很多在 Fragment 时代养成的习惯要反过来做。比如在 Fragment 时代，页面 A 跳转 B 之后，如果你希望 A 在某个时机做点事情，可能会监听 A 的 onResume 回调；但到了 Compose 里，页面"回到前台"不是一个事件，而是 Lifecycle.Repeater 或者某个状态量的恢复，你更多是依赖 A 的 LaunchedEffect 重新执行。理解这个思维切换，比学会 API 本身更重要。

2.3 时序图中可见的设计取舍

把 Compose Navigation 的时序图画出来之后，你会发现它的设计里有几个明显的取舍，这些取舍直接决定了它的使用姿势。

第一，导航状态是"单向数据流"式地流向 UI。NavHost 并不会"被通知"去渲染某个页面，而是 NavController 的背栈状态变化后，NavHost 作为一个 Composable，在重组时读到新的当前条目，从而“顺带”渲染新页面。当你画时序图时，消息箭头一个方向往下走，很少出现循环回调，这就是单一数据流的好处。

第二，背栈状态是一个"有序列表 + index"，而不是一个"嵌套栈集合"。这意味着导航在时序上是"串行"的：一次 pop 必须等上一次 navigate 的状态稳定之后才能正确处理，所以 Compose Navigation 会在导航事件上做排队和"自动重复最后一次导航"的处理。如果你手动在很短的时间内连续调 navigate 两次，可能导致第一次被丢弃。这个坑我在后面实操环节里会专门演示。

第三，生命周期状态是"跟随导航被动派发"的。在时序图里，你会看到 NavController 在完成背栈修改后，对每一个 BackStackEntry 做 Lifecycle 的升降级，这个动作发生在导航事务的收尾阶段，而不是导航动作的一开始。这就导致了经典问题：A 页面在 navigate(B) 之后，A 的"失去焦点"回调与 B 的"获得焦点"回调的先后次序，并不以你的代码书写顺序为准，而是以背栈状态稳定后的生命周期派发为准。

3. 核心流程拆解：一次导航完整时序

这一部分是我们的核心，我直接用文字把关键时序流程展开，这样无论你是在手机上看还是在电脑上看，都能跟着箭头走一遍。我尽量不引入过多源码细节，以语义和时机为主。

3.1 应用启动：从 setContent 到首个目的地

一个 App 启动到显示第一个页面，在时序图上要经过这么几站：

1. Activity 的 onCreate 里调用 setContent。
2. setContent 内部，我们创建 NavController 实例。这是第一个关键对象。注意 NavController 在这里会被放进一个 remember 语义的容器里，保证重组时不丢失。
3. 把 NavController 传给你的 NavHost。
4. NavHost 在首次组合（composition）时读取 NavController 当前的背栈。此时背栈为空，它会向 NavController 请求“起始目的地”（startDestination）。
5. 拿到 startDestination 的 route 后，NavController 生成对应的 BackStackEntry，并把状态推送给背栈。
6. NavHost 观察到背栈有变化，开始对 route 做匹配，找到 you kai触发对应的 composable 函数进行组合。
7. 这个 Composable 首次进入 composition，内部如果有 LaunchedEffect 或者 collectAsStateWithLifecycle，开始执行各自的初始化逻辑。

整个过程在时序图上是一条从 Activity 到 NavController 到 BackStackEntry 再到 Composable 的直线，中间没有回环。你只需要记住一句话：NavHost 渲染的是“NavController 背栈当前状态”的投影，首屏只是这个投影的第一次落地。

这里实际工程里最容易踩的坑是：在 NavController 还没准备好背栈之前就去访问 currentBackStackEntry。有些追求性能的同学会在 setContent 里试图提前读取 currentDestination 来动态决定某些 UI，结果拿到的是 null。我的建议是，任何依赖导航状态的读取，都放到 composable 的副作用生命周期里去拿，而不是在创建 NavController 的同一时刻同步拿。

3.2 页面跳转：navigate() 调用后发生了什么

假设现在在 A 页面，用户点击按钮，调用 navController.navigate("B")。这行代码在时序图上可以拆成六个阶段：

**阶段一：外部调用。**你的 Composable 持有一个 NavController 引用（一般通过 NavBackStackEntry 间接获取），调用它的 navigate()。此时 NavController 内部开始一次导航事务。

**阶段二：生成新条目。**NavController 解析你传入的 route（比如 "B?id=123"），创建一个新的 BackStackEntry，并把解析出来的参数（arguments）塞进这个新条目。也就是说，参数在导航的这一瞬间就已经“固化”到目标条目的 arguments 里了。之后目标 Composable 读取参数靠的是这个条目，而不是你调用时传的原始对象。

**阶段三：入栈并更新状态。**NavController 把这个新条目压入 backStack 的栈顶，同时把当前栈的 index 指向新条目。这些操作在 NavController 内部是以状态变更的形式完成的，所有订阅这个状态的 Composable 都会被标记为需要重组。

**阶段四：NavHost 重组并匹配目的地。**NavHost 观察到背栈状态变化，对栈顶的 route 做匹配，找到对应的 composable 函数，把当前条目的 BackStackEntry 传进去，触发该 Composable 进入组合。这里注意一个细节：NavHost 并不是“切换页面”，而是把原来 A 的组合从界面树上移除或保留（取决于生命周期与可见性），再把 B 的组合放到界面上。

**阶段五：生命周期切换。**NavController 在导航事务内部对背栈中各个条目执行 Lifecycle 升降级。正常情况下，B 条目会被提升到 RESUMED，A 条目被推到 STARTED 或 CREATED。这个切换是“批量”处理的，所以你在 A 和 B 里同时观察生命周期变化的话，看到的是一个交错序列，而不是 A 先彻底销毁、B 再启动的串行序列。

**阶段六：转场动画与内容可见。**NavHost 根据你在 NavHost 或 composable() 里配置的 enterTransition / exitTransition，执行过渡动画。这里又要提醒一句：转场动画的时机和生命周期切换的时机并不严格对齐，动画期间两个页面都可能是 RESUMED 状态。

如果用一段文字伪时序来呈现：

点击事件 -> LoginScreen 持有 NavController -> navController.navigate("detail?id=100") NavController -> 创建 BackStackEntry(route="detail?id=100", args=[id=100]) -> backStack.push(entry) -> backStack.index = entry.index -> 状态变更通知（NavigationState 更新） NavHost(Composable) -> 读取到新的栈顶条目 -> 与目的地图匹配，命中 detail composable -> 重组，渲染 DetailScreen(entry) Li叔 lifecycle -> detailEntry.lifecycle -> RESUMED -> homeEntry.lifecycle -> STARTED -> DetailScreen 中度 LaunchedEffect 执行

3.3 返回栈操作：popBackStack 与生命周期联动

返回操作在时序图上要复杂一些，因为牵涉到“找目标条目”和“中间条目清理”两个环节。

假设当前栈是 A -> B -> C，用户在 C 页面按返回键。系统返回事件会先被 Activity 捕获，由 Navigation 组件的 OnBackPressedDispatcher 转发给 NavController。NavController 拿到事件后，并不会“无脑出栈”，而是先检查栈里有没有能回去的页面。如果栈中只有一个条目，这个事件会继续向上传递，可能最终由 Activity 处理，退出整个 App。

如果是正常的 C 返回 B，NavController 的时序是：

1. NavController 从 backStack 里 pop C 条目。
2. 栈顶指针回退到 B 条目。
3. 通知 NavHost 重组，渲染 B 页面。
4. 对 C 条目执行 Lifecycle 降级（到 DESTROYED 的边缘状态，但注意并不是立刻销毁，条目可能暂时还留在内存里）。
5. 对 B 条目执行 Lifecycle 升级回 RESUMED，同时触发 B 页面从“后台”回到“前台”时的副作用重新执行。

这整个流程里最值得记住的是：**popBackStack 不是一个同步销毁的指令，而是把背栈状态“回拨”一格，剩下的一切都是状态驱动的副作用。**而且如果你用 popBackStack(route, inclusive) 的方式一次性弹出多个页面，NavController 会在一次事务中移除中间所有条目，然后统一做生命周期调整。

实际操作中最常见的疑难杂症是：在弹回某个页面后，希望把某些数据带回那个页面。有些人直接在 popBackStack 之后取 NavController.previousBackStackEntry，在时序上往往会拿到 null 或者错误的条目。为什么？因为弹栈和回调上一条目的拉取的时机不对，需要等背栈稳定。更稳的做法是通过 SavedStateHandle 在目标页面的 ViewModel 里观察，或者使用导航结果回传的机制。这点在下面第 4 节里会写实操代码。

3.4 参数传递与结果回传：时机比表面更重要

Compose Navigation 的参数体系分成两块：路由参数（来自 route 字符串）和导航结果（类似 startActivityForResult 的返回数据）。很多人在传参时踩的坑，都可以用时序来解释。

路由参数是在创建 BackStackEntry 那一刻“快照”下来的。也就是说，你用字符串拼接的方式在 route 里写入参数之后，目标页面拿到的是一份基于字符串解析结果的 Bundle，后续你修改原始 ViewModel 里的数据，目标页面不会自动同步。所以如果两个页面需要共享某个动态变化的业务数据，正确的姿势是用 Activity 级 ViewModel 或者信息分享框架共享，而不是通过导航参数“传值”。

导航结果回传则是更典型的异步时序：当前页面通过调用前一个条目的 SavedStateHandle.set(key, value) 写入结果，然后调用 popBackStack() 返回。目标页面如何感知结果？它不能“同步读取”，只能通过 SavedStateHandle 的 LiveData（或者把状态转成 Compose state）来观察，在组合的过程中拿到这个值。基于时序图的视角：写入结果的时刻是 C 页面还在栈顶时，读取结果的时刻是 B 页面再次获得状态并重组的时刻，这两个时刻之间隔着一次完整的弹栈事务。所以你在 B 页面“回到前台”的 LaunchedEffect 里同步读，不一定读得到，但通过观察 SavedStateHandle 的方式一定能在重组时读到。

4. 实操：从零搭建带导航的 Compose 工程

上面讲了这么多原理，下面进入可以直接抄作业的环节。我会用一个“登录页 -> 列表页 -> 详情页”的经典结构，把 Navigation-Compose 的完整实操串一遍，包含参数传递、结果回传和多背栈这几个最容易出问题的点。

4.1 依赖与基础工程准备

首先确认你的 Android 工程使用的是 Compose BOM，并且把 Navigation 依赖加进来。在 app 模块的 build.gradle.kts 里：

dependencies { // 建议使用 BOM 统一管理所有 Compose 相关依赖 implementation(platform("androidx.compose:compose-bom:2024.06.00")) implementation("androidx.navigation:navigation-compose:2.8.0") }

我建议直接把版本号用 BOM 里的约束管理，不要单独在 Navigation 上开一个新版本。因为 Compose 的版本升级往往伴随 Compose 编译器版本调整，而 Navigation-Compose 和 Compose 本身是打包适配过的，混着用容易在编译器版本上出现奇怪问题。

4.2 NavHost 与目的地注册

接下来创建 NavController 并注册 NavHost。最标准的姿势是：

class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { MyAppTheme { AppNavHost() } } } } @Composable fun AppNavHost() { val navController = rememberNavController() NavHost( navController = navController, startDestination = "login" ) { composable("login") { LoginScreen(navController) } composable("list") { ListScreen(navController) } composable("detail/{id}") { entry -> val id = entry.arguments?.getString("id") ?: "" DetailScreen(navController, id) } } }

这里有几个关键点值得展开。第一，rememberNavController() 必须放在组件层级中能被 NavHost 看到的位置，通常在 Activity 或接近 Activity 层级的可组合函数里创建。如果在一个会被频繁销毁重建的 Composable 里创建，会导致导航状态丢失。第二，startDestination 必须是已经在 NavHost 里注册过的 route，否则运行时会直接抛 IllegalArgumentException，这个异常信息有时候不太明显，我身边不少人排查了半天才发现是 route 拼写不一致。

第三，带参数的 route 在注册时用的是模板形式 "detail/{id}"，实际跳转时要把真实值拼进去：navController.navigate("detail/100")。如果参数是数字类型，建议还是先用字符串拼，然后在目标 Composable 里解析成具体类型。因为 Navigation 内部实际上是把 route 当字符串匹配的，参数类型转换是你自己的责任。

4.3 带参数导航与类型安全

上面那种字符串拼接的方式有个明显的痛点：类型不安全，写错了编译期不报错，运行期才 crash。Navigation-Compose 2.8 版本开始支持基于 Kotlin 序列化的类型安全路由，我强烈建议新项目直接上这种写法，尤其在团队规模超过三个人的时候收益非常明显。

// 定义一个可序列化的 route 类 @Serializable data class DetailRoute( val id: String, val fromList: Boolean = false ) // 注册方式 composable<DetailRoute> { entry -> val route = entry.toRoute<DetailRoute>() DetailScreen(navController, route.id, route.fromList) } // 跳转方式（类型安全，无需字符串拼接） navController.navigate(DetailRoute(id = "100", fromList = true))

以我的实践看，类型安全路由最大的好处还不是防拼错，而是重构友好。以前字符串 route 模式下，你把某个页面从 "detail" 改成 "detailV2"，全项目所有 navigate 调用都得翻一遍，漏一个就运行期闪退。改成类型安全后，全局重命名一个类，编译器直接告诉你哪里没改完，省下的排查时间非常可观。

但类型安全方案也有一个注意点：需要额外引入 kotlinx-serialization 插件和依赖，如果项目本身没启用过序列化，要记得在 app 的 build.gradle 里配置 kotlinx-serialization 的 plugin 和依赖项，同时所有 route 类都要标上 @Serializable。团队里有人会漏掉这一步，导致编译报一堆“类没有序列化器”的错误。

参数传值这块还有个进阶技巧：如果参数是可空类型，路由参数默认在解析时得到的值是空字符串，而不是 null。你想把空字符串还原成 null，可以用route.value?.takeIf { it.isNotEmpty() }这种判断兜底。否则页面上可能出现不该出现的空壳数据。

4.4 底部导航与多背栈组合的时序要点

商业 App 里最常见的导航结构是底部 Tab + 每个 Tab 内部各自维护页面栈。Navigation-Compose 对多背栈的支持是原生级别的，但用法和很多人想象的不一样。

正确姿势是通过 NavHost 的 navController 创建多个子 NavController，或者用一个 NavHostController 配置 saveState 与 restoreState 实现 Tab 间栈状态保存。直接上代码：

@Composable fun MainScreen() { val navController = rememberNavController() Scaffold( bottomBar = { BottomNavigation { // 三个 Tab 项：首页、搜索、我的 } } ) { padding -> NavHost( navController = navController, startDestination = "main/home", modifier = Modifier.padding(padding) ) { composable("main/home") { HomeScreen() } composable("main/search") { SearchScreen() } composable("main/profile") { ProfileScreen() } } } }

这是“单 NavHost + 三个兄弟页面”的模式，不需要手动管理多背栈。如果你想实现“每切一个 Tab，之前 Tab 里的二级页面全部保留”的效果，就得在切换 Tab 时使用 navigate + saveState/restoreState 参数：

navController.navigate("main/search") { popUpTo(navController.graph.findStartDestination().id) { saveState = true } launchSingleTop = true restoreState = true }

这里的时序玄机：popUpTo 并不是“销毁”，而是“把栈顶pop到指定目的地，同时保存状态”。saveState = true 会把当前 Tab 栈内所有条目保存起来，restoreState = true 则在你下一次切回这个 Tab 时把保存的栈恢复出来。画成时序图的话，Tab 切换就是“保存当前栈镜像 -> 恢复目标栈镜像”的交换过程，两个栈的时间线在 NavController 内部是分段存储的。

4.5 转场动画与进入/退出时机

Navigation-Compose 2.8 之后对转场动画的定制能力增强了很多，你可以在 NavHost 层面统一配置，也可以在单个 composable 目的地层面单独配置：

NavHost( navController = navController, startDestination = "home", enterTransition = { fadeIn(animationSpec = tween(300)) }, exitTransition = { fadeOut(animationSpec = tween(300)) }, ) { composable("home") { HomeScreen() } composable("detail") { DetailScreen() } }

时序图里的一个细节是：enterTransition 控制的是新页面进入时的动画，exitTransition 控制的是旧页面退出时的动画，两套动画默认同时启动。如果你希望旧页面先退出、新页面再进入（横滑转场那种常见的母版模式），需要额外配置如下参数：

popExitTransition = { slideOutHorizontally(targetOffsetX = { it }) }

有些开发者写完后发现动画“闪一下”或者“两个页面叠在一起”，多半是 enterTransition 和 popExitTransition 没配置好，两个页面的组合顺序和动画顺序产生了视觉冲突。用我自己的实测数据来看，给 Activity 主题开启 windowOptOutEdgeToEdgeEnforcement 之类的窗口配置时，动画问题尤其明显，建议动画调试时把系统主题切到无状态栏模式，容易定位问题。

5. 常见问题与排查技巧实录

这部分把我在实际开发里遇到的几个经典 Navigation-Compose 问题，按照“现象 -> 排查思路 -> 解决方式”的结构整理出来，都是可以直接套用的经验。

5.1 问题一：连续快速导航导致页面错乱

现象：用户快速点击两次"进入详情"，结果跳到了两层深度一样的详情页，甚至出现返回时一次要连续返回两次的情况。

原因：在时序上，两次 navigate() 都是在极短的时间内被 NavController 接收的。由于 NavHost 的组合渲染是异步的，第一次导航引起的原势组合还没稳定时，第二次导航就已经入栈了，两个同 route 的 BackStackEntry 同时存在于栈里。

解决：把跳转封装成防抖函数，并配合 launchSingleTop = true：

navController.navigate("detail/100") { launchSingleTop = true }

需要注意的是，launchSingleTop 只对同一个 route 有效。如果你的两次 navigate 携带的参数不同（比如 detail/100 和 detail/101），它依然会生成两个条目。这种场景下最好在业务层让对方先确认，或者用 500ms 的防抖窗口控制。我自己一般直接写一个扩展函数，统一处理：

fun NavHostController.safeNavigate(route: String, delayMillis: Long = 500) { if (System.currentTimeMillis() - lastNavigateTime > delayMillis) { navigate(route) { launchSingleTop = true } lastNavigateTime = System.currentTimeMillis() } }

5.2 问题二：返回后前一个页面的状态没有恢复

现象：A 页面有一个输入框，跳到 B 再返回后，A 页面输入框内容还在，但滚动位置常常回到顶部；又或者某些 UI 状态（如下拉加载完成的标记）丢失了。

原因：滚动位置和输入框内容用的状态保存机制不一样。输入框如果你使用的是 rememberSaveable，它会跟随 BackStackEntry 的 SaveableStateHolder 保存；滚动位置如果是 ListState 且没有经过 rememberSaveable，进程级别重建或页面被系统回收时就会丢。

解决：在需要使用记忆状态的地方统一用 rememberSaveable；自定义数据类型记得写 Saver。比如 LazyColumn 的 state：

val listState = rememberLazyListState()

这个因为内部是基于 Saveable 的，所以在导航回来时能自动恢复。但如果你的页面状态本身是个普通 object 或者复杂的业务数据，别指望 Navigation 帮你做，这类建议通过 ViewModel 持有，因为 ViewModel 在返回栈条目销毁前都保留在 NavBackStackEntry 的 ViewModelStore 里。

5.3 问题三：ViewModel 的生命周期与页面不一致

现象：页面从 B 返回到 A，B 的 ViewModel 里部分数据还在，但某些协程已经取消，再回到 B 时发现状态丢了，或者 onCleared 被调用的时间点和预期不同。

原因：这是时序理解不到位导致的。B 页面在 pop 时，其 BackStackEntry 的 Lifecycle 会走到 DESTROYED，But 这个销毁过程并不一定发生在页面从屏幕上消失的瞬间，而是发生在背栈事务稳定之后。如果你观察 B 的 ViewModel，会发现它可能比界面消失晚一点才 onCleared。反过来，如果你从 B 页面跳转到 C，B 只是变成 STARTED 而不是 DESTROYED，所以 ViewModel 还在，但协程会因为你开了 repeatOnLifecycle(STARTED) 而取消。

解决：把一切数据加载的协程生命周期与 ViewModel 自身解耦，不要在 composable 的 LaunchedEffect 里执行长任务，而是要建立在 ViewModel + repeatOnLifecycle 的标准体系上。此时即便导航时序变化，数据也是由 ViewModel 持有的，最多只是 UI 订阅的启停问题，不会出现数据丢失。

5.4 问题四：深层链接（Deep Link）启动后参数时序错乱

现象：通过通知栏点击拉起 App，跳转到某个页面，但该页面读取参数时偶尔拿到默认值，特别是 App 还没在后台运行、需要冷启动时最常出现。

原因：冷启动时序里，Activity 会先创建 NavController，然后 NavController 处理 deep link 时会尝试先创建整个导航图，再恢复目标目的地。如果你的参数是在 NavHost 注册后的某个初始化副作用里读取的，这一步的时序会和 deep link 的恢复时序冲突，导致读取过早。

解决：参数读取不要放在目的地 composable 的外层，要放在该目的地对应的 BackStackEntry 拿到之后再读。稳妥做法是用 NavBackStackEntry 的 arguments 包裹一层：

composable("detail/{id}") { entry -> val backStackEntry = entry val id = backStackEntry.arguments?.getString("id") // 确保在 backStackEntry lifecycle 至少 STARTED 后再读取业务数据 LaunchedEffect(backStackEntry) { // 这里再做数据加载 } }

这个问题的本质还是读取时机与导航状态的不同步。只要能意识到时序图上的“消息先入栈、后渲染、再读参数”这个顺序，绝大多数参数问题都能靠调整读取位置解决。

5.5 排查技巧：用 Log 还原一张运行期时序图

理论上线上的问题很难像本地一样频繁调 Log，但如果本地能复现，我建议你把 NavController 当前背栈的变化用日志打出来，观察它和界面变化之间的时间差。

创建一个自定义 NavController 子类，重写 navigate/popBackStack，打印当前 backStack 里每个元素的 route 和生命周期状态。这样你就能非常直观地看到“哪一步先发生、哪一步后发生”：

class DebugNavController(context: Context) : NavHostController(context) { override fun navigate(route: String, navOptions: NavOptions?, navigatorExtras: Navigator.Extras?) { Log.d("NavDebug", "navigate: $route") super.navigate(route, navOptions, navigatorExtras) dumpBackStack("afterNavigate-$route") } private fun dumpBackStack(action: String) { val list = backStack.map { it.destination.route + " -> " + it.lifecycle.currentState } Log.d("NavDebug", "$action : $list") } }

然后你在实际运行时观察，会发现很多诡异现象的规律性比想象中强，基本都是生命周期升降和背栈内容变更的次序问题。这套日志封装我后来直接放到团队的组件库里了，排查导航问题效率至少提升一倍。

6. 多背栈场景下的时序陷阱与设计建议

多背栈在时序图上是另一个复杂度区间，单独拿出来写一写，因为它的坑和单背栈完全不是一个级别，没有图的引导真的很容易踩进去。

6.1 多 Tab 切换时的“状态镜像”机制

之前提到多 Tab 切换会用 saveState/restoreState 实现状态镜像。这个机制的时序实质是：每个 Tab 是一段相对独立的“子时间线”，而 NavController 内部用 map 保存了每个 Tab 的 backStack 快照。你切 Tab 时，当前 Tab 的快照被存进 map，目标 Tab 的快照被取出并覆盖到当前 backStack 上。

这意味着两件事：第一，Tab 之间天然共享同一个 NavController 的全局状态，比如你如果给导航图设置了全局的 deep link，每个 Tab 都能命中；第二，不同 Tab 之间并不共享各自 BackStackEntry 的 ViewModelStore，所以 Tab 切换不会导致 ViewModel 重建，但你在某个 Tab 里 push 的多层页面会在你离开该 Tab 时“冻结”，而不是销毁。

6.2 设计建议：把 Tab 导航提升为一级架构决策

很多项目把 Tab 导航当成“一个 Activity 里的多个元素”来设计，等页面层数多了就开始痛苦。我的建议是，设计阶段就把 Tab 容器当成一个独立的导航域来看待。具体含义是：每个 Tab 的子 NavHost 应该放在一个稳定的父 Composable 下，父级的重组不要波及 Tab 页面内部的 NavHost，避免频繁反序列化导航图。

比如你在主界面里用 pager 滑动 Tab 容器，滑动导致的水平偏移变化往往会让整个容器重组，如果没有做隔离，底下每一个 Tab 的 NavHost 都被迫参与重组，而 NavHost 重组的成本是遍历整棵导航图进行目的地匹配。复杂的导航图 + 频繁容器重组 = 卡顿。解决办法是用 remember 包裹每个 Tab 的 NavHost 实例，或者用 SubcomposeLayout 这类手段做内容隔离。

时序陷阱的最佳规避方式就是画图。在接入多 Tab 之前，花半小时把“用户切 Tab -> 保存快照 -> 恢复快照 -> 子树重组”的时序画出来，基本能提前避开 80% 的问题。因为我真见过有团队到上线前一天才来找我，说“Tab 切来切去 App 会崩”，一查就是快照恢复时生命周期状态错乱导致的宿主 ViewModel 崩溃。

7. 写在最后：一点实战体会

我自己从 Fragment 时代一路写过来，最大的感受是 Compose Navigation 比旧导航体系更“诚实的暴露时序关系”，也因此对开发者理解抽象机制的要求更高。以前 Fragment 时代的导航，你把页面替换、入栈出栈的细节藏在系统里，学 API 背模板就能跑；但现在 Navigation-Compose 把导航状态裸露在 Compose 状态流里，你不了解状态什么时候变、谁观察状态、生命周期什么时候切，就很容易写出间歇性 Bug。

强烈建议每一位准备深度使用 Compose Navigation 的开发者，把主场景的时序图亲手画一遍。不需要用什么专业工具，纸笔或者白板都行，只要你把“谁调用谁、谁观察谁、数据何时写入、状态何时恢复”这四个要素捋顺了，你会发现自己对 Navigation 的理解瞬间从“会用”进阶到“懂它的脾气”。下次遇到奇怪的 bug，修起来也更有底气。