过期闭包是闭包机制与React渲染模型共同作用的自然结果，典型表现为：定时器总打印初始值、异步更新丢失历史、事件处理中状态滞后；解决方式包括函数式更新、useRef同步、正确添加useEffect依赖。
React 函数组件中，“过期闭包”（stale closure）不是 bug，而是闭包机制与 React 渲染模型共同作用下的自然结果——关键在于你是否意识到它正在发生。它最典型的信号是：**回调里读到的 state 或 props 不是你点击、输入或触发动作时界面上显示的那个值**。
看这三类典型现象，基本就能确认是过期闭包
✅ 定时器/间隔任务总打印初始值
比如 useEffect 里用 setInterval 打印 count，无论你点多少次 +1，控制台始终输出 “Count is: 0”。这是因为 log 回调在首次渲染时就捕获了当时的 count（0），之后再没更新。
✅ 异步操作后状态更新“重置”或“丢失历史”
监听 MQTT、WebSocket 或 setTimeout 后调用 setState，发现数组每次只加一个新项，旧数据没了；或者 setCount(count + 1) 总是变成 1、1、1……而不是 1、2、3。这是因为回调里用的 count 是挂载时的快照，不是最新值。
✅ 事件处理函数里读取的状态“滞后一步”
比如有个开关按钮，点击后 status 变成 'loading'，但紧接着发请求的回调里 console.log(status) 还是 'idle'。这不是 setState 慢，而是那个回调函数早在 status 改变前就定义好了，锁住了旧值。
适用于用户提出以下需求时：“构建赢回活动（win-back campaign）”、“重新激活已流失订阅者（re-engage lapsed subscribers）”、“执行重新授权 / 重新同意（re-permission / re-consent）清理”或“清理无效联系人列表（sunset my dead list）”；输出一个闭环式再激活方案——包括：流失用户群组（lapsed-cohort）定义、分阶段优惠阶梯（staged offer ladder）、重新授权（re-consent / re-p
想在回调里拿到最新 State？别等它“同步”，要主动“取”
React 的 setState 本身是异步批量的，不存在“同步获取最新 state”的 API。所谓“同步拿到”，其实是绕过闭包捕获，让回调每次都能访问当前真实值。有三种可靠方式：
-
函数式更新（首选，用于 setState 场景）：
把 setState(prev => ...) 当作默认写法。它不依赖外部变量，而是由 React 在更新时传入最新 prev，天然避开闭包陷阱。适用于计数、追加数组、基于旧值计算等。 -
useRef + useEffect 同步（用于副作用回调读值）：
声明 const ref = useRef(initial)，再用 useEffect(() => { ref.current = value; }, [value]) 实时更新 ref。在定时器、socket.onmessage 等回调里，直接读 ref.current —— 它永远是最新值，且不会触发重渲染。 -
把依赖加进 useEffect 数组（仅当逻辑允许重新执行）：
如果 effect 本身可以也应当随某个 state 变化而重建（比如重新连接带参数的 WebSocket），那就把它加入依赖项。React 会销毁旧 effect、创建新闭包，从而“刷新”捕获的值。但注意：加错依赖可能引发无限循环或重复订阅。
一个简单判断原则：这个值是“用来算新状态”，还是“用来做副作用决策”？
如果是前者（比如 setCount(count + 1)、setState([...prev, newItem])），一律用函数式更新；
如果是后者（比如 socket.onclose 里要根据当前 status 记日志、定时器里要检查 isRunning 标志位），就用 useRef 存一份快照，回调里读 ref.current。
两者不冲突，可以共存。真正要避免的，是直接在闭包里引用 useState 声明的变量，又不把它放进依赖数组、也不用函数式更新——那几乎一定会掉进过期闭包的坑里。
