为什么“状态越集中”，RN 项目反而越卡
@[toc]
如果你做过一段时间 RN，大概率经历过下面这个过程：
- 一开始：
useState写得很舒服 - 状态多了：开始集中管理
- Redux / Context / Store 上了
- 列表开始卡、动画掉帧
- 开始疯狂
memo、useCallback - 发现——没救
很多人会把锅甩给 FlatList，但其实FlatList 只是把问题放大了。
真正的问题是：
状态集中之后，渲染传播半径失控了。
先说结论：状态集中，本质是“广播”
我们先把话说透。
所谓“集中状态”，意味着什么？
- 一个 state
- 被很多组件依赖
- 任意一个字段变化
- 都会向所有订阅者发信号
一句话总结：
集中状态 = 广播式更新
而 RN 里，列表、动画、手势，全部都怕广播。
一个你肯定写过的“合理结构”
我们从一个非常常见、非常“规范”的写法开始。
场景
一个列表，每一项可以点赞。
全局状态（Redux / Context / Store 都一样）
{likedMap:{'1':true,'2':false,'3':true,...}}列表组件
function List() { const likedMap = useSelector(state => state.likedMap) return ( <FlatList data={data} renderItem={({ item }) => ( <Item item={item} liked={likedMap[item.id]} /> )} /> ) }逻辑完全正确，对吧？
一次点赞，引发了什么？
我们不讲抽象概念，直接走一遍执行链路。
当你点了一个 item 的点赞：
dispatch(toggleLike(id))likedMap生成新对象useSelector命中List组件 re-renderFlatList重新执行renderItem- 所有
Item重新参与 diff
注意一个细节：
不是 Item 自己 re-render，
而是整个列表重新走了一遍 render 流程。
为什么 memo / useCallback 救不了你？
你可能会说：
“我 Item memo 了啊”
const Item = React.memo(...)但问题是：
- 父组件已经 re-render
- renderItem 已重新执行
- props 已重新计算
memo 只能挡住最后一层组件执行，
挡不住前面的 render 传播。
这在 Web 项目里为什么没这么明显？
这是很多人误判的根源。
Web 有三层“兜底”
- 浏览器 DOM diff 极其成熟
- 合成层可以跳过大量重排
- 掉一两帧用户感知不强
RN 没有
- render 就是 JS 执行
- JS 卡，动画立刻掉
- 列表一滚，问题全部暴露
所以 RN 会逼你面对一个现实：
你到底让多少组件，参与了这次状态更新？
Demo：全局状态 vs 局部状态
我们用一个最小 Demo 看差异。
错误示例：全局状态控制 item 点赞
function Page() { const [likedMap, setLikedMap] = useState({}) return ( <FlatList data={list} renderItem={({ item }) => ( <Item item={item} liked={likedMap[item.id]} onLike={() => setLikedMap(prev => ({ ...prev, [item.id]: !prev[item.id] })) } /> )} /> ) }问题点：
- 任意一次点赞
- Page re-render
- FlatList re-render
- 全部 item 被波及
正确示例：局部状态下沉到 Item
function Item({ item }) { const [liked, setLiked] = useState(false) return ( <Pressable onPress={() => setLiked(v => !v)}> <Text>{liked ? '❤️' : '🤍'}</Text> </Pressable> ) }现在变化变成：
- 只有一个 Item
- 一个 state
- 一个 re-render
那 Redux / Zustand / Context 该怎么用？
重点不是“用不用”，而是用在什么层级。
Redux：不适合什么？
不适合：
- 点赞
- 勾选
- 展开
- hover / focus
- 高频 UI 交互
这些状态有一个共同点：
变化频率高，但影响范围极小
Redux 适合什么？
- 列表数据本身
- 分页 / 筛选条件
- 用户信息
- 权限、配置
一句话：
改了就应该影响整个页面的状态，才配放 Redux。
Zustand 的优势在哪？
const liked = useStore(state => state.likedMap[id])这里真正关键的是：
selector 是订阅边界
- store 变没关系
- selector 没变就不 re-render
所以 Zustand 在 RN 列表里天然更顺手。
Context：隐形杀手
<Context.Provider value={{ likedMap }}>只要 value 是新对象：
所有 useContext 的组件，全部重绘
这也是为什么 Context 在列表里最容易“悄悄拖死性能”。
状态粒度拆分的实用规则
给你一套非常好用的判断标准。
你在决定“这个状态放哪”时，只问 3 个问题：
- 它变化频率高吗？
- 它影响多少个 item？
- 改它，是否“业务上就该全刷”？
判断结果：
| 状态类型 | 推荐位置 |
|---|---|
| 列表数据 | Redux / Query |
| 筛选条件 | 页面 state |
| 点赞 / 展开 | Item 本地 |
| 动画进度 | sharedValue |
为什么“状态集中”在 RN 是反模式？
不是集中本身错，而是集中得太早、太粗。
在 RN 里更合理的哲学是：
结构集中，交互分散。
- 页面结构：集中管理
- Item 行为：就地消化
总结
如果你只记住一句：
RN 项目不是“状态越集中越好”，
而是**“状态传播半径越小越安全”**。
FlatList 不背锅，
状态模型才是性能的第一责任人。