React Native使用State实现页面导航为何非社区主流方案？

你贴出的通过顶层useState存储页面索引、switch判断渲染对应组件的导航写法，我见过不少初学者刚接触RN的时候都会想到，在极小规模的练手项目里确实可以正常运行，但存在很多你暂时没感知到的边界问题，这也是它没有成为社区通用方案的核心原因。

你当前的实现逻辑大致是这样：

const [screen, setScreen] = useState(0)

const returnScreen = () => {
    switch (screen) {
        case 0:
           return <AccountScreen/>
    }
}

点击菜单修改screen的状态值就能切换渲染的组件，逻辑看起来非常简单直接。目前社区文档推荐的主流导航方案是基于@react-navigation/native、@react-navigation/native-stack这两个依赖包实现的。

自实现state导航方案的隐忧 #

• 完全缺失原生端导航能力适配
  这种纯React层的组件切换，本质是把旧组件卸载、挂载新组件，完全不会触发系统层面的导航行为：iOS端的边缘侧滑返回、Android端的系统返回键拦截、平台默认的页面转场动画、不同页面切换时状态栏样式/导航栏样式的自动变更，这些能力全部需要你手动写代码适配。光是处理「按Android返回键不退出APP、而是返回上一页」这一个需求，就要写全局事件监听、自己维护页面跳转历史栈，很容易出适配bug。
• 页面状态默认会丢失
  switch逻辑下，非当前激活的页面组件会被直接卸载，你在页面上的临时操作状态完全留不住：比如列表滑到一半切去其他页面，再切回来列表会直接回到顶部；表单输入了一半的内容、弹窗的展开状态，切页后会全部重置。如果要保留这些状态，你需要手动给每个页面做状态缓存、改逻辑为控制组件display: none隐藏而非卸载，维护成本会随着页面数量增加快速上涨。
• 复杂场景下维护成本爆炸
  你现在只有5-7个平级页面，逻辑看起来简单，但只要加一点常见的导航需求，代码复杂度会陡增：比如页面间传参（列表跳详情要携带条目ID）、跳转后回传参数（选地址页返回上一页带回选中的地址）、嵌套导航（底部Tab栏里每个Tab再套独立的页面栈）、全屏模态弹窗页面，这些场景下你需要自己维护历史栈、自己管理每个跳转的参数存储、自己区分不同跳转类型的渲染逻辑，写出来的代码冗余度极高，还容易出逻辑漏洞。
• 存在天然性能损耗
  所有页面的渲染逻辑都挂载在顶层组件下，每次切页修改state都会触发顶层组件全量重渲染；同时你没法做页面懒加载，首屏启动时就要把所有页面的依赖全部加载完成，页面一多就容易出现切页卡顿、首屏启动慢的问题。

为什么React Navigation成为社区通用选型 #

@react-navigation/native这套方案能成为社区默认选择，本质是把导航场景下所有的脏活、累活、边界适配全做完了：

• 默认提供匹配双平台设计规范的转场动画、手势交互，开箱支持iOS侧滑返回、Android返回键拦截，不需要额外写适配代码
• 自动维护页面栈与页面状态，栈内非顶层页面不会被随意卸载，切回时能保留离开时的交互状态
• 提供标准化的简洁API：用navigation.navigate()跳页面、navigation.goBack()返回、自带传参/接参、嵌套导航、Tab导航、抽屉导航、模态页等全场景支持，社区生态成熟，遇到问题很容易找到现成解决方案
• 做了大量性能优化，支持页面懒加载、转场动画跑在UI线程，切页流畅度远高于手写的简单state切换逻辑

如果你当前做的是纯练手demo、页面全是平级简单页面，不想引入额外依赖，这套自实现方案完全可以临时用。但如果是要上线的正式应用，哪怕页面数量少，也更推荐直接用React Navigation，没必要在基础能力上重复造轮子——你花一周踩坑自己写的导航，体验和健壮性大概率还不如开源库开箱即用的效果。

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