先把结论放在前面：Fragment 事务是异步的、有队列的，回退栈是 FragmentManager 维护的一条独立记录，两者都不是"调用即生效"。 show/hide 不走销毁流程，切换快但视图状态与内存常驻；replace + addToBackStack 走完整生命周期，能回退但每次都重建视图。选哪种，取决于是否需要回退和是否在乎内存——这是判断题，不是知识点。
Fragment 事务与回退栈是高频考点，但答好的人不多。这篇带你从零理清它的原理、用法和坑。
事务的机制：为什么 commit 后立刻找不到视图
FragmentTransaction.commit() 不会立刻执行，它只是把事务对象塞进 FragmentManager.mPendingActions 队列，真正的执行发生在 FragmentManager 的执行时机——通常是主线程消息循环的下一轮（FragmentManager 通过 Handler 调度），或由 commitNow() 立刻同步执行。
这个机制带来三个直接推论，答出来就是层次：
① 事务可以合并。连续多次 add/hide 会在一轮里一起执行，所以中间状态不会渲染出来，这也是为什么"批量改动要放进同一个 commit { } 块"是官方推荐——它既合并执行，又保证要么都成功、要么都回滚。
② executePendingTransactions 之后的执行结果可以查。commit() 返回 int（写入的事务 back stack index），commit 的 ktx 版本可传 Int 类型的生命周期状态。
③ 执行结果可以等。commitNow() 立刻执行且不允许排队，commitNowAllowingStateLoss() 同上但不检查状态保存时点。
// 批量放进同一个事务块：合并执行 + 原子性
parentFragmentManager.commit {
setReorderingAllowed(true) // 允许 reorder 与 add/hide 混排
setCustomAnimations(enter, exit)
replace<DetailFragment>(R.id.container, DetailFragment.newInstance(id))
addToBackStack("detail:$id")
}.commit()
setReorderingAllowed(true) 是个容易被忽略但很实用的开关：它让 FragmentManager 先处理所有 remove/hide 再处理 add/show，避免中间态闪烁，同时不必为了顺序正确而被迫 commitNow() 分多次提交。
回退栈的三条规则
addToBackStack 压入的是一条操作记录（不是 Fragment 实例本身），回退时系统按记录反向执行对应的逆向操作。规则有三条必须记清：
- 一个事务算一条记录。在同一个
commit {}块里做多次操作，它们绑在一起，回退时一起撤销。 - 回退栈与
show/hide不兼容。hide是状态操作不是栈操作，FragmentManager 无法用一条栈记录还原它，所以混用会让回退行为与预期不符。 - 返回键的层级。
OnBackPressedDispatcher的优先级是：FragmentManager 后栈 → Activity 的onBackPressed。所以要先判断有没有 Fragment 后栈，避免"按返回没反应"的困惑。
// 顶层 Activity 统一接管返回
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
override fun handleOnBackPressed() {
if (supportFragmentManager.backStackEntryCount > 0) {
supportFragmentManager.popBackStack()
} else {
isEnabled = false
onBackPressedDispatcher.onBackPressed() // 交回系统，触发退出
}
}
})
最后那两行是这段代码真正的考点：回调默认 isEnabled = true 会拦截返回键，必须在放行前把自己置为 false 再转交，否则会死循环。忘写就是"按返回没反应"。
最常见的坑是
在 commit 后立刻 findViewById 新 Fragment 的视图，事务未执行取到 null。
因为事务还没跑，容器里还是旧 Fragment（或空）。三种修法，各有适用场景：
// 修法一：延迟到下一轮（最常用）
parentFragmentManager.commit {
replace<DetailFragment>(R.id.c, DetailFragment.newInstance(id)) }
.commit()
parentFragmentManager.executePendingTransactions() // 强制立刻执行，随后能拿到视图
// 修法二：本来就想立刻执行（但不能与状态保存冲突）
parentFragmentManager.commit {
replace<DetailFragment>(R.id.c, DetailFragment.newInstance(id)) }
.commitNow()
// 修法三：不依赖时序（推荐）
// 交给新 Fragment 自己在 onViewCreated 里操作自己的视图
这里要讲清 commitNow 的代价：它不允许排队，会立刻执行当前队列里所有待处理事务，所以当队列里还有别人的事务时调用它，等于替别人做了决定。更重要的是它不能在 onSaveInstanceState 之后调用（否则抛 IllegalStateException），commitAllowingStateLoss 则是允许丢状态——两者都在掩盖问题，不是推荐的常态写法。
还有一个更隐蔽的坑：Fragment 事务与回退栈最好的预防是自动化——检查与断言替人守着每个坑位。可落地的三条：① Lint 开启 Fragment 相关检查，拦截 commitAllowingStateLoss；② 在基类 BaseActivity 里统一封装 navigateTo(fragment, tag)，把 setReorderingAllowed(true) 与 addToBackStack 固化，业务代码不再直接碰 transaction；③ 单测里断言"回退后屏幕恢复到原状态"，用 Espresso + FragmentScenario 能覆盖。
三条高频追问
问：show/hide 和 replace 有什么区别，怎么选？
show/hide 只改可见性，不触发 onCreateView/onDestroyView，切换是即时的，代价是所有页面视图常驻内存（大列表、多层富文本会明显吃内存），且不能进回退栈。replace 走完整生命周期，内存友好、能回退，代价是每次切换重建视图。选型判据：需要回退、页面重、或页面吃内存用 replace；需要频繁快速切换（底部导航、Tab 切换）且页面轻量用 add + show/hide。 再补一句实践：现在更推荐 Navigation 组件，它在 replace 之上解决了状态保存、参数传递、动画与多层导航的统一。
问：为什么 addToBackStack 之后 onDestroyView 走了但 onDestroy 没走？
因为压栈时 Fragment 实例被保留、视图被移除（onCreateView/onDestroyView 走一遍），这样返回时能重建视图、保留实例字段。如果连 onDestroy 也走了，返回时就是全新实例——这正是 replace + 压栈的默认行为。在栈中的 Fragment 实例是活的、视图是死的，这个区分是答好这题的钥匙。
问：事务的状态保存冲突怎么正确处理？
FragmentManager.isStateSaved 为 true 时提交事务会抛 IllegalStateException，因为此时状态已被 onSaveInstanceState 保存、无法回滚。正确做法是延迟到 ON_START 之后再提交（用 lifecycleScope.launch { repeatOnLifecycle(STARTED) { ... } }），而不是用 commitAllowingStateLoss 绕过。绕过会丢状态，但往往丢的是"用户刚点的那个 tab"这种刚发生的交互，代价比抛异常更难排查。
落到项目里怎么做
一条能直接落地的规则：业务代码不允许直接调 commit()，一律走基类封装或 Navigation 组件。这一条能消灭掉绝大多数事务相关的时序 bug。
配套实践三条：① 封装 navigateTo(fragment, tag, allowBackStack)，内部统一 setReorderingAllowed(true)、统一是否入栈的判断；② 返回键只在 Activity 一处处理，用 addCallback 并记得放行时置 false；③ 所有 commit 后需要立刻拿视图的场景，改为在新 Fragment 自己的 onViewCreated 里操作，顺便消除时序依赖。
给正在准备面试的你
这题的得分点在把"异步 + 队列"讲成机制，而不是把 commitNow 讲成技巧。推荐这条答题线：先讲事务入队、下一轮执行 → 由此推出三种修法（延迟执行 / 立刻执行 / 不依赖时序）→ 讲回退栈存的是"操作记录"而非实例 → 由此推出"栈中 Fragment 实例活、视图死" → 最后用 show/hide 与 replace 的选型收尾。顺带把 isStateSaved 与 commitAllowingStateLoss 的取舍、OnBackPressedCallback 需置 false 放行这两个细节补上，整道题的层次就齐了。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：Fragment-通信演进：从接口回调到共享-ViewModel
下一篇预告：ViewPager2-与-Fragment：懒加载的正确实现
有任何问题欢迎在评论区留言交流。
