RN 列表状态设计 Checklist

子玥酱 （掘金 / 知乎 / CSDN / 简书同名）

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- [使用这份 Checklist 的正确方式](#使用这份 Checklist 的正确方式)
- [状态是否"真的属于 Item"](#状态是否“真的属于 Item”)
- - 基础判断问题
  - 快速危险信号
- 状态变化的"扩散半径"
- - 给每个状态标一个扩散等级
  - 快速自检问题
- 状态来源是否"可控"
- - 高风险来源列表
  - 错误示例：直接吃全局对象
  - [Checklist 推荐姿势](#Checklist 推荐姿势)
- 状态变化频率评估
- - 高频状态黑名单
  - [Checklist 判断法](#Checklist 判断法)
- [Item 是否具备"状态隔离能力"](#Item 是否具备“状态隔离能力”)
- - 必查项
  - [Checklist 快速判断](#Checklist 快速判断)
- 状态是否"越层传播"
- - 典型越层路径
  - [Checklist 建议](#Checklist 建议)
- [终极 Checklist 汇总表](#终极 Checklist 汇总表)
- 总结

使用这份 Checklist 的正确方式

在开始之前，先明确怎么用它：

新页面设计阶段 → 先过一遍
列表卡顿 → 对着排查
CR 时 → 专门盯状态流向
性能优化没效果 → 回头重新勾

它解决的不是"怎么优化"，而是更底层的：

"这个状态，到底该不该进列表？"

状态是否"真的属于 Item"

基础判断问题

对每一个传入 renderItem 的 state / props，都问自己 3 个问题：

这个状态变化时，是否必须影响这一行的 UI？
这个状态是否和 item 的数据生命周期一致？
如果只改这一行，其它行是否应该完全不受影响？

只要有一个问题回答是「否」------
这个状态就不该进列表。

快速危险信号

如果你在 Item props 里看到这些名字，先警惕：

isEditing
currentTab
filter
sortType
user
theme
language
loading
scrollY

这些 80% 都是列表污染源。

状态变化的"扩散半径"

这是 RN 列表性能的核心判断维度。

给每个状态标一个扩散等级

你可以在脑子里给状态分 3 级：

L1：单行状态
- 只影响当前 item
- 例如：是否点赞、是否展开
L2：局部列表状态
- 影响列表子集
- 例如：选中态、分页边界
L3：页面 / 全局状态
- 理论上影响所有 item

L3 状态默认禁止进列表。

快速自检问题

问自己一句话就够：

"这个状态一变，会不会让 100 行一起重新 render？"

如果答案是「会」，那你已经知道问题在哪了。

状态来源是否"可控"

高风险来源列表

以下来源的状态，一旦进列表，要特别小心：

Context
Redux（未做 selector 拆分）
全局 Store（返回整个对象）
页面顶层 useState

不是说不能用，而是必须明确：

你拿的是"值"，还是"变化源"。

错误示例：直接吃全局对象

tsx 复制代码

const user = useUser(); // 返回整个 user 对象

<Item item={item} user={user} />

任何一个 user 字段变化，都会让列表整体重绘。

Checklist 推荐姿势

只取最小必要字段
尽量在列表外计算
传"结果"，不传"来源"

tsx 复制代码

const canEdit = user.role === "admin";

const renderItem = useCallback(
  ({ item }) => <Item item={item} canEdit={canEdit} />,
  [canEdit]
);

状态变化频率评估

这是一个极容易被忽略，但杀伤力巨大的点。

高频状态黑名单

如果状态具备以下特征，严禁进入列表渲染链路：

每秒变化多次
跟动画 / 手势有关
跟输入实时变化有关

典型包括：

scrollY
gesture progress
animated value
input text（未提交态）

Checklist 判断法

你只需要问一句：

"这个状态，是不是有可能一秒内变 10 次以上？"

如果是，那它的归宿只有两个：

Reanimated Shared Value
原生层 / UI 线程

绝对不是 React render。

Item 是否具备"状态隔离能力"

即使状态是合理的，也要看 Item 能不能扛住。

必查项

每一个 Item 组件，都应该满足：

是否 React.memo
props 是否稳定（引用是否变化）
是否存在匿名函数
是否存在 inline object / style

Checklist 快速判断

如果 Item 没有 memo：

直接判定为"性能不合格"

如果 Item memo 了，但 props 每次都在变：

等同于没 memo

状态是否"越层传播"

这是 RN 项目后期最难救的坑。

典型越层路径

复制代码

Page State
  ↓
FlatList
  ↓
Item
  ↓
Item 子组件

如果一个状态：

在 Page 定义
在 Item 使用
中间跨了 3 层

高度危险。

Checklist 建议

越层 ≥ 2 层 → 重新审视设计
列表 item 内的状态，优先 item 内自己维护
跨层共享，必须证明"不可替代"

终极 Checklist 汇总表

你可以直接贴在项目 Wiki 里。

检查项	是否通过
状态是否真正属于 item	⬜
状态变化是否只影响单行	⬜
是否避免页面级状态进列表	⬜
是否避免 Context 直通 Item	⬜
是否避免高频状态进入 render	⬜
Item 是否 memo 且 props 稳定	⬜
是否存在跨层状态传播	⬜
是否只传"结果"不传"来源"	⬜

只要有 2 条以上没勾 ，这个列表迟早会出性能问题。

总结

你会发现一个很残酷但真实的结论：

RN 列表的性能上限，不在 FlatList，
而在你"愿不愿意克制状态"。

状态越集中、越方便、越"统一管理"，

列表的性能空间就越小。