从词法环境到 Fiber 架构：彻底终结 React 函数组件的状态闭包陷阱
引言
在实现无限滚动（Infinite Scroll）功能时，开发者常会遇到一个现象：明明数据已经返回，但通过 setList([...list, ...res.data]) 更新后，页面数据却出现了覆盖、丢失或反复加载旧数据的"灵异现象"。本文将从 JavaScript 词法环境与 React Fiber 架构的双重维度，剖析这一问题的根源------闭包陷阱（Stale Closure）。
一、 现象描述：消失的状态更新
在无限滚动的实现中，我们通常会在滚动触底时触发请求。如果使用普通的状态更新方式：
javascript
const [list, setList] = useState([]);
const loadMore = async () => {
const res = await fetchData();
// 隐患点：这里的 list 引用可能已经"过时"
setList([...list, ...res.data]);
};当请求是异步完成时，loadMore 函数所捕获的 list 变量属于该函数被创建时的那个"渲染快照"。如果用户快速滚动触发了多次加载，后一次加载可能捕获的是前一次尚未更新的旧 list，导致数据被覆盖。
二、 深度探究：词法环境与 Fiber 状态模型
1. 词法环境（Lexical Environment）的快照特性
在 JavaScript 中，每当函数执行，都会创建一个词法环境。对于 React 函数组件而言，每一次 Render 都是一次独立的函数调用。
- Render N： 存在一个
list变量，指向内存地址0x001。 - Render N+1：
useState返回一个全新的list变量，指向内存地址0x002。
如果异步操作在 Render N 阶段被触发，它闭包中引用的 list 永远指向 0x001。即使 React 已经进入了 Render N+5，该异步回调依然在旧的地址中寻找数据。
2. 双缓存 Fiber 机制
React 的更新机制基于双缓存 Fiber 树。一个组件实例在特定时间点关联两个 Fiber 节点：
- Current Fiber： 代表当前屏幕上显示的 UI 状态。
- WorkInProgress (WIP) Fiber： 代表正在内存中构建、即将更新的 UI 状态。
当调用 setList(prev => ...) 时，React 并不从当前的闭包中取值，而是从 WIP Fiber 的状态队列中取出最实时的状态值作为 prev 参数传入。
三、 逻辑对比：普通更新 vs 函数式更新
通过 Mermaid 序列图可以清晰地观察到两者的差异：
React 内部状态 (Fiber) 闭包环境 (List V1) 用户/滚动事件 React 内部状态 (Fiber) 闭包环境 (List V1) 用户/滚动事件 情况 A: 直接更新 setList([...list, data]) 此时 list 仍为 V1 情况 B: 函数式更新 setList(prev => [...prev, data]) 触发 loadMore 请求数据并返回 setList([V1, ...newData]) 触发 loadMore 请求数据并返回 获取最新的 Fiber State (可能是 V2) setList([V2, ...newData])
四、 结论
setList(prev => [...prev, ...res.data]) 的本质是脱离闭包依赖。
- 安全性： 它确保了更新逻辑始终基于 React 内部维护的最实时状态（Latest State），而非当前函数执行上下文中的快照。
- 原子性： 在高频触发的场景下（如滚动、定时器、并发请求），函数式更新能够保证状态转换的连续性，有效规避"状态闭包陷阱"。
对于开发者而言，理解 React 渲染即快照（Render as Snapshot）的概念是进阶的关键。在处理涉及异步逻辑的状态修改时，优先使用函数式更新应当成为一种最佳实践。