新北市网站建设_网站建设公司_内容更新_seo优化

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

前言

如果你 RN 项目越做越大，开始出现下面这些情况：

• 页面越切越卡
• 列表状态莫名其妙残留
• 一堆 reset、cleanup 写得到处都是
• 明明没改业务，性能却一版比一版差

那你大概率不是写错了代码，而是一开始就没想清楚一个前置问题：

这个页面，到底是“用完就销毁”，还是“长期住在内存里”？

这个问题不解决，后面不管你用 Redux、Zustand 还是 Jotai，本质上都只是在补洞。

很多人没意识到：页面模型，才是状态设计的地基

在 RN 项目里，页面其实只有两种命运。

一种是离开就 unmount，组件销毁、状态清空，生命周期非常干净。

另一种是为了体验、性能或者导航需要，被设计成常驻页面。切走了，但还活着。

问题在于，大多数状态设计，默认假设的是第一种模型。

而一旦你在后期引入页面常驻，这个假设就彻底失效了。

一个非常真实的开发过程

很多项目其实都是这么走过来的：

一开始先把页面功能写出来，用useState、Redux 把数据跑通。

后面发现页面切换有白屏、有闪烁，于是加了页面缓存、常驻。

然后开始出现各种奇怪问题：

• 上一次的筛选条件还在
• 列表滚动位置不对
• loading 状态怎么都回不去

于是你开始在各种地方加：

• useFocusEffect
• 手动 reset
• 各种 if 判断

这时候你会觉得 RN 很麻烦，但真正的问题是：

状态在设计时，假设页面会被销毁，而现实是它从没被销毁过。

同一份状态，在不同页面模型下，命运完全不同

来看一个非常简单、非常常见的例子。

function ListScreen() { const [page, setPage] = useState(1); useEffect(() => { fetchList(page); }, [page]); return <List />; }

如果这是一个非常驻页面，一切都很自然。

你进页面，page从 1 开始；
你翻页，page变大；
你离开页面，组件销毁；
下次再进，一切重新开始。

但一旦这个页面变成常驻，事情就完全不一样了。

你切走又切回来，page还是上一次的值。
从用户角度看，这往往是不符合预期的。

这时候很多人会补一段：

useFocusEffect(() => { setPage(1); });

看似解决了问题，其实只是在给错误的状态模型打补丁。

常驻页面下，状态必须“自己解释自己”

在页面会被销毁的模型里，状态是天然合法的。

因为页面在，状态就在；
页面没了，状态自然没了。

但在常驻页面里，状态必须回答几个问题：

• 它什么时候才算有效？
• 它什么时候应该失效？
• 它跨时间还成立吗？

如果你没有在代码里明确这些答案，那默认结果只有一个：

这个状态，永远有效。

而这，几乎一定是错的。

为什么“状态一集中”，问题会放大得更快

很多 RN 项目一旦页面常驻，就会顺手把状态往全局丢。

理由也很直觉：反正页面不销毁，放全局也没关系。

但事实正好相反。

页面常驻的时候，全局状态的生命周期会被无限拉长。

你本来只是想表达：

“这是这个页面内部的一点状态。”

但实际效果却变成了：

“这是整个 App 运行期间的一部分状态。”

于是你会看到：

• 上一次进入页面留下的 UI 状态，影响下一次
• 切换账号后，某些列表状态还在
• 某些 flag 一旦设成 true，就再也回不去了

状态设计的正确顺序，其实很简单

状态设计，第一步真的不是选库。

正确的顺序应该是：

先想清楚，这个页面会不会常驻。
再想，这个状态是否允许跨时间存在。
接着问，它是否应该跨页面存在。
最后，才决定用useState、Context 还是 Store。

只要这个顺序反过来，后面一定会开始“修状态”。

一个非常好用的自检方式

你可以在写任何一个状态时，问自己三个问题：

• 如果用户离开十分钟再回来，这个状态还合理吗？
• 如果数据源已经变化，这个状态还能用吗？
• 如果切换账号，这个状态应该保留吗？

只要有一个答案你犹豫了，这个状态就不该默认常驻。

把生命周期写进代码里，而不是写在脑子里

在常驻页面下，显式绑定生命周期，反而是好事。

useFocusEffect( useCallback(() => { initState(); return () => cleanupState(); }, []) );

这不是多写代码，而是在告诉未来的你和同事：

这个状态，只在页面聚焦期间有效。

总结

页面常驻本身不是问题。

真正的问题是：

你还在用“页面会销毁”的状态思维，去设计一个“页面永远活着”的系统。

一旦你意识到这一点，很多之前觉得“RN 很难搞”的问题，其实都会变得非常清晰。