@[toc]
回头看 RN 项目里所有卡顿严重的列表，你会发现它们几乎都有一个共同点：
状态没有边界。
不是 FlatList 写错了，不是 memo 没加，而是——
你根本不知道：哪些状态，正在影响哪些 item。
先给你这张“状态分区图”
我们先不解释，直接给结论。
在 RN 列表里，所有状态都应该被强制放进这 4 个区：
┌─────────────────────────┐ │ 全局业务态 │ Redux / Query │ 用户信息 / 接口数据 │ └─────────────────────────┘ ┌─────────────────────────┐ │ 页面结构态 │ useState / Store │ 排序 / 过滤 / Tab │ └─────────────────────────┘ ┌─────────────────────────┐ │ Item 交互态 │ local / atom / selector │ 点赞 / 选中 / 展开 │ └─────────────────────────┘ ┌─────────────────────────┐ │ 瞬时表现态 │ useSharedValue │ 动画 / 手势 / 滑动 │ └─────────────────────────┘任何一个状态放错区，都会产生渲染扩散。
为什么“状态分区”在 RN 里这么重要？
在 Web 项目里，你可能会觉得：
“多 render 几次也没啥”
但在 RN 里：
- render 就是 JS 执行
- JS 被占，动画就掉帧
- 掉帧，用户马上感知
RN 是一个对状态错误极度敏感的环境。
我们从一个最容易踩雷的例子开始
场景
一个 Feed 列表，每一条都有：
- 点赞
- 评论展开
- 播放状态
很多人会这么写
function FeedPage() { const [likedMap, setLikedMap] = useState({}) const [expandedMap, setExpandedMap] = useState({}) const [playingId, setPlayingId] = useState(null) return ( <FlatList data={list} renderItem={({ item }) => ( <Item item={item} liked={likedMap[item.id]} expanded={expandedMap[item.id]} playing={playingId === item.id} /> )} /> ) }功能 OK，性能隐患巨大。
这段代码的问题不在 Item，在“状态层级”
我们拆解一次点赞发生时的链路：
- setLikedMap
- FeedPage re-render
- FlatList re-render
- renderItem 重新执行
- 所有 Item 重新计算 props
哪怕只有一个 item 状态变化
状态分区错了，memo 是救不了你的
你可能会说：
const Item = memo(...)但注意：
- 父组件已经 re-render
- renderItem 已重新执行
- props 计算已发生
memo 只能减少最后一层，
挡不住前面的雪崩。
正确的分区方式长什么样？
我们按分区图重写。
1. 全局业务态（Redux / Query）
// list 数据本身constfeedList=useSelector(...)特点：
- 低频变化
- 改了本来就要全列表更新
2. 页面结构态（页面级）
const [activeTab, setActiveTab] = useState('hot')特点：
- 改一次，全列表刷新是合理的
- 用户有心理预期
3. Item 交互态（关键）
function Item({ item }) { const [liked, setLiked] = useState(false) const [expanded, setExpanded] = useState(false) return ... }或者：
const liked = useStore(s => s.likedMap[item.id])特点：
- 高频变化
- 必须局部更新
- 禁止向上传播
4. 瞬时表现态（动画）
const scale = useSharedValue(1)特点：
- 不进 React render
- 不进 JS 主链路
一个“状态放错区”的真实性能事故 Demo
错误示例：Context 管点赞
const LikeContext = createContext({}) function Page() { const [likedMap, setLikedMap] = useState({}) return ( <LikeContext.Provider value={{ likedMap, setLikedMap }}> <FlatList ... /> </LikeContext.Provider> ) }Item 使用
const { likedMap, setLikedMap } = useContext(LikeContext)结果是：
任意一次点赞 = 所有 item 全部重绘
正确的 Context 使用姿势（如果非用不可）
const LikeContext = createContext(null) function Item({ id }) { const liked = useContextSelector( LikeContext, v => v.likedMap[id] ) }但注意：
如果你已经写到这里，
Zustand / Jotai 通常更简单。
用“状态分区图”快速做 Code Review
你在 Review RN 列表代码时，只问 4 个问题：
- 这个状态放在这里，会影响多少 item？
- 它变化频率高不高？
- 改了之后，父组件会不会 render？
- 这次 render，是不是“业务必须的”？
答不上来，基本必有性能坑。
用 RN 的分区思维，反看 Web 项目
你会发现：
- 很多 Web 卡顿，其实也是状态污染
- 只是浏览器帮你兜住了
- RN 把这些问题提前暴露了
这也是为什么：
RN 项目写顺了，回去写 Web，代码会自动变干净。
总结
如果你只记住一句：
RN 列表的性能，本质是“状态传播半径”的控制能力。
FlatList 只是放大镜，
状态分区才是解法。
