大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！
文章目录
- 前言
- RN 为什么总是“先暴露问题”
- RN 的世界没有这些“缓冲垫”
- Web 的“顺”，很多时候是偶然的
- 看起来很合理的 Vue 列表
- 但用 RN 的视角一看，问题非常明显
- RN 的性能标准，本质是“设计标准”
- 规则一：渲染范围必须是可控的
- 规则二：列表父组件，不能参与交互态
- 规则三：UI 状态和业务状态必须拆开
- 如果 Web 按 RN 标准设计，会发生什么变化？
- 变化一：你会开始主动拆“渲染边界”
- 变化二：你会开始警惕“看不见的订阅关系”
- 变化三：你会重新审视 keep-alive 和缓存
- 一个用 RN 思维重写的 Vue 列表 Demo
- 问题版（扩散模型）
- RN 思维改造版（局部模型）
- 你会发现一个非常重要的事实
- RN 的性能标准，其实是一种“工程自律”
- 为什么这套标准，值得反向迁移到 Web
- 总结
前言
很多 Web 项目在性能问题上，长期存在一种“错觉”：
能跑就行
Chrome 很快
用户机器也越来越好了
但如果你同时做过 RN 和 Web，你很容易产生一个反直觉的结论：
Web 项目之所以“没问题”，并不代表设计是对的。
很多时候，只是浏览器在替你兜底。
RN 为什么总是“先暴露问题”
我们先说一个现象：
同样的业务逻辑：
- Web 上跑得还行
- RN 上立刻卡、掉帧、掉动画
很多人第一反应是：
RN 性能差
但你真正深入之后会发现：
RN 只是更早、更直接地把问题摊在你面前。
RN 的世界没有这些“缓冲垫”
在 Web 里你习以为常的东西，在 RN 里几乎都不存在：
- 浏览器高度优化的 DOM diff
- 原生滚动线程
- GPU 合成层兜底
- 滚动与 JS 逻辑天然解耦
RN 的渲染链路是非常直白的：
state 变化 → render → diff → bridge/JSI → native你写的每一行状态代码，都会被真实“算账”。
Web 的“顺”，很多时候是偶然的
我们来看一个 Web 项目里非常常见的写法。
看起来很合理的 Vue 列表
<template> <Item v-for="item in list" :key="item.id" :active="item.id === activeId" @click="activeId = item.id" /> </template>在 Web 里：
- 点击流畅
- 滚动没事
- Lighthouse 分数也不差
于是我们会下意识得出结论：
没问题
但用 RN 的视角一看，问题非常明显
这段代码意味着：
- 任意一次点击
activeId改变- 整个列表重新参与 render 计算
只是浏览器把这件事做得足够快，你才没感知到。
RN 的性能标准，本质是“设计标准”
RN 教会你的，并不是某个 API，而是几条极其残酷但非常真实的规则。
规则一：渲染范围必须是可控的
在 RN 里，你很快就会意识到：
一次 state 更新，影响多少组件，必须能说清楚。
因为说不清楚，就一定会卡。
而 Web 项目里，很多时候是：
“反正问题不大”
规则二：列表父组件，不能参与交互态
RN 里几乎是共识：
- FlatList 的父组件
- 不应该因为 item 的交互而更新
否则，卡是必然的。
规则三：UI 状态和业务状态必须拆开
点赞、选中、展开，这些状态：
- 生命周期短
- 范围小
- 频繁变化
在 RN 里放进 Redux，几乎等于“自杀”。
但在 Web 项目里，这种写法极其常见。
如果 Web 按 RN 标准设计，会发生什么变化？
这是最关键的问题。
变化一：你会开始主动拆“渲染边界”
以前在 Web 里你可能会写：
const state = reactive({ list: [], activeId: null, loading: false })然后整个页面都依赖它。
但 RN 的思维会逼你问一句：
activeId 真的有必要让整个页面都知道吗？
于是你会自然改成：
- 列表只关心数据
- item 自己关心交互态
变化二：你会开始警惕“看不见的订阅关系”
在 RN 里，Context 是出了名的“隐形杀手”。
因为你很难一眼看出谁在订阅它。
同样的事情，在 Web 里天天发生：
- provide / inject
- 全局 store
- composable 里读全局状态
只是你没把它当性能问题。
变化三：你会重新审视 keep-alive 和缓存
Web 项目里，keep-alive 经常被当成“性能优化神器”。
但 RN 的经验会提醒你：
页面不销毁 ≠ 页面不更新
如果页面里的响应式依赖还在：
- 定时器还在
- store 还在
- 订阅还在
那它依然在“消耗你”。
一个用 RN 思维重写的 Vue 列表 Demo
问题版（扩散模型）
<script setup> const activeId = ref(null) </script> <Item v-for="item in list" :key="item.id" :active="item.id === activeId" />问题本质：
- 父组件承担了 item 的交互状态
- 每次点击，所有 item 都被牵连
RN 思维改造版（局部模型）
<Item v-for="item in list" :key="item.id" :item="item" />Item 内部：
<script setup> const active = ref(false) </script>变化非常关键：
- 渲染扩散被掐断
- 列表层只负责“展示集合”
你会发现一个非常重要的事实
当你开始用 RN 的性能标准写 Web：
- 页面结构更清晰
- 状态职责更单一
- 组件边界更稳定
- 后期改需求更安全
这不是因为 Web 变慢了，而是因为：
你终于开始为“最坏情况”设计了。
RN 的性能标准，其实是一种“工程自律”
可以这样总结：
- RN 不允许你偷懒
- Web 允许，但代价会在未来出现
RN 的性能约束，本质上是在逼你：
- 尊重渲染模型
- 尊重状态传播路径
- 尊重组件边界
为什么这套标准，值得反向迁移到 Web
因为现在的 Web 项目，正在变成：
- 更复杂的交互
- 更长的列表
- 更重的状态
- 更接近 App 的使用场景
也就是说：
Web 正在走向 RN 的问题空间。
那你为什么不提前用 RN 的标准约束自己？
总结
如果你同时做过 RN 和 Web，你迟早会认同这句话：
RN 的性能问题，是 Web 项目的“未来预警”。
你在 RN 里学会的所有克制、拆分和边界意识，
都会在 Web 项目里，变成长期稳定性的红利。