iOS SwiftUI NavigationStack 状态恢复

摘要：SwiftUI 导航可以用路径状态表达用户所在的页面栈。本文介绍类型化目的地、路径更新、深层入口和状态恢复时的业务校验。

一、用数据表达导航路径

导航路径可以由目的地值组成，让程序化跳转和返回都成为状态变化。目的地类型应表达稳定业务身份，而不是携带整个可变模型。

将目标视图注册集中在导航容器附近，避免不同页面重复声明互相矛盾的目标规则。页面通过动作请求跳转，路由宿主决定具体路径更新。

二、避免路径携带易变对象

数据对象可能在导航后被更新或删除。路径中保存稳定标识，目标页根据标识重新读取业务数据，并对无效标识显示恢复状态。

路由类型应能安全编码和解码，适合需要保存路径的场景。版本变化后旧路径可能无法解析，应用需要回退到安全入口。

三、区分推入、返回和重置

推入目的地会增加路径长度，返回则移除末尾节点。流程完成时可能需要清空路径或回到特定根页面。每种动作都应对应清楚的用户语义。

不要通过多个互相独立的布尔值描述导航状态，例如同时维护“显示详情”和“显示设置”。单一路径更容易确保只有一个一致的栈状态。

四、处理外部入口

通知或应用内链接进入深层页面时，构造所需路径并验证数据可用性。目标内容可能已删除，或用户尚未登录；根据流程先完成身份校验，再展示目标页。

外部输入应严格解析。路径中的标识不能代替权限检查。

五、恢复路径状态

路径状态可以参与场景恢复，但业务数据要重新验证。进程重建后用户可能已经退出账户，之前的目的地不能继续显示敏感内容。

多窗口场景中，每个窗口应拥有自己的导航路径，避免场景之间互相覆盖。

六、检查与测试

覆盖正常推入和返回、快速重复跳转、外部入口、数据删除、账户切换及状态恢复。测试应观察目的地和用户可见内容，而非依赖导航容器的内部实现。

七、总结

SwiftUI 导航路径适合表达可观察的页面栈。使用稳定标识、单一一致的路径状态，并在恢复或外部跳转时重新验证业务数据，能让导航更容易测试和恢复。