企业官网建设流程全解析

@[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，在“状态层级”

我们拆解一次点赞发生时的链路：

1. setLikedMap
2. FeedPage re-render
3. FlatList re-render
4. renderItem 重新执行
5. 所有 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 个问题：

1. 这个状态放在这里，会影响多少 item？
2. 它变化频率高不高？
3. 改了之后，父组件会不会 render？
4. 这次 render，是不是“业务必须的”？

答不上来，基本必有性能坑。

用 RN 的分区思维，反看 Web 项目

你会发现：

• 很多 Web 卡顿，其实也是状态污染
• 只是浏览器帮你兜住了
• RN 把这些问题提前暴露了

这也是为什么：

RN 项目写顺了，回去写 Web，代码会自动变干净。

总结

如果你只记住一句：

RN 列表的性能，本质是“状态传播半径”的控制能力。

FlatList 只是放大镜，
状态分区才是解法。