iOS 14导航栈修改异常咨询：与iOS 13的行为差异解析

这个问题我在适配iOS 14的时候也踩过一模一样的坑，确实和苹果新增的长按返回导航历史功能直接相关，下面给你拆解清楚来龙去脉：

问题场景回顾 #

初始导航栈：[A, B, C]（C为当前显示的栈顶控制器）
操作步骤：在C中获取当前栈 → 移除B和C → 添加新控制器D → 将新栈[A, D]设置给导航控制器
iOS 13结果：栈为[A, D]（完全符合预期）
iOS 14结果：栈变为[C, A, D]（C未被移除反而跑到了栈底）

核心原因：iOS 14新增的导航历史追踪逻辑 #

苹果在iOS 14给UINavigationController加了一套内部导航历史栈，专门用来支撑长按返回按钮展示完整导航路径的功能。这个历史栈和我们平时操作的viewControllers数组是绑定但独立的两个结构：

• iOS 13及以前，导航控制器只靠viewControllers数组管理栈，直接修改数组会立即生效，没有额外校验
• iOS 14及以后，导航控制器会同时维护这个内部历史栈，用来记录用户的「合法导航操作」（比如push、pop、popToRoot这类符合用户操作逻辑的行为）

当你直接修改viewControllers数组时，iOS 14的导航控制器会做一个关键校验：
如果当前正在显示的控制器（也就是C）不在你设置的新栈[A,D]里，它会判定这是一个「非常规修改」——因为正常的用户导航流程中，必须先从C pop回到A，再push到D，而不是直接把当前显示的控制器从栈里硬删掉。

为了保证长按返回的历史记录不混乱，导航控制器会强制保留当前显示的控制器C在栈的最前端，再把你设置的新栈[A,D]追加到后面，最终就出现了[C, A, D]的异常结果。

验证与修复思路 #

• 按正常导航流程操作：先调用popToViewController(A, animated: false)回到A，再push D，iOS 14下栈会正常变为[A,D]，因为这个操作完全符合导航历史的追踪逻辑
• 如果一定要直接修改栈，需要确保当前显示的控制器包含在新栈中，或者先手动将导航控制器的当前页面切换到新栈中的某个控制器（比如A），再设置新栈

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