使用 Codex 修改 React 项目时有一种 Bug 非常隐蔽代码没有报错页面也能正常运行但事件回调、定时器或异步函数里拿到的却一直是“旧数据”。常见表现包括setInterval里的 count 永远停在初始值用户已经切换账号回调里还是旧 user搜索关键词更新了请求函数却继续使用旧 keyworduseCallback明明存在却执行了之前的逻辑useEffect加了空依赖后只运行一次但数据再也不更新为了解决重复执行Codex不断删除依赖最后状态越来越不可靠。这种问题通常叫Stale Closure过期闭包。它并不是 React “没有更新状态”而是某个函数仍然记住了它创建时的旧变量。一、什么是Stale Closure先看一个经典例子function Counter() { const [count, setCount] useState(0); useEffect(() { const timer setInterval(() { console.log(count); }, 1000); return () clearInterval(timer); }, []); return ( button onClick{() setCount(count 1)} {count} /button ); }用户点击按钮后页面上的count会正常变成1 2 3 4但定时器可能一直输出0 0 0 0原因就在这里useEffect(() { ... }, []);这个 Effect 只在第一次渲染时创建。此时它拿到的count 0后面组件虽然重新渲染但旧定时器内部的函数仍然引用第一次渲染时的count。这就是过期闭包。二、为什么Codex容易写出这种代码因为从局部逻辑看useEffect(() { startTask(); }, []);很合理。尤其当开发者要求这个逻辑只执行一次不要重复运行。Codex最直接的处理就是使用空依赖数组。但“Effect只创建一次”同时也意味着它内部捕获的状态可能只来自第一次渲染。因此不能把不要重复执行简单理解成依赖数组全部删除Effect 的依赖应该由它实际读取的数据决定。三、最直接的方法补齐依赖前面的例子可以改成useEffect(() { const timer setInterval(() { console.log(count); }, 1000); return () clearInterval(timer); }, [count]);这样每次count改变旧定时器清理 → 创建新定时器 → 新函数拿到最新count虽然能解决旧状态问题但也要考虑这个副作用是否真的应该随着 count 重新创建如果定时器本身不应该反复重建就需要其他方案。四、更新状态时优先使用函数式写法另一个经典错误useEffect(() { const timer setInterval(() { setCount(count 1); }, 1000); return () clearInterval(timer); }, []);由于闭包中的count一直是0所以每次实际执行的都是setCount(1)结果页面可能永远停在1如果只是基于旧值计算新值更推荐setCount(prev prev 1);完整写法useEffect(() { const timer setInterval(() { setCount(prev prev 1); }, 1000); return () clearInterval(timer); }, []);这里不再依赖闭包中的count。React 会把当前最新状态传给prev。这类场景包括数字累加数组追加切换布尔状态根据旧对象生成新对象。五、不要为了消除ESLint警告删除依赖项目中经常会看到React Hook useEffect has a missing dependencyCodex 有时为了让 lint 通过会建议// eslint-disable-next-line react-hooks/exhaustive-deps或者直接useEffect(() { loadData(userId); }, []);即使 Effect 实际使用了userId。这种处理很危险。例如用户从/users/1001切换到/users/1002组件没有卸载但userId已经变化。Effect 因为空依赖不会重新执行页面仍然加载1001的数据。正确方向通常应该是useEffect(() { loadData(userId); }, [userId]);ESLint 的 Hooks 依赖提示很多时候是在告诉你代码正在读取一个会变化的值但没有声明这个关系。六、useCallback也会拿到旧状态例如const handleSave useCallback(() { saveUser(user); }, []);如果user后续发生变化handleSave仍然可能保存创建回调时的旧用户数据。应该根据真实依赖写成const handleSave useCallback(() { saveUser(user); }, [user]);或者尽量缩小依赖const handleSave useCallback(() { saveUser(user.id, user.name); }, [user.id, user.name]);需要注意useCallback的作用不是“让函数永远不变”。它应该表达当这些依赖不变时函数引用可以复用。如果为了追求函数引用稳定而故意遗漏依赖就可能把旧状态永久保存下来。七、useMemo也存在同样问题例如const filteredUsers useMemo(() { return users.filter( user user.status selectedStatus ); }, [users]);这里漏掉了selectedStatus当筛选状态变化时users没有变化 → useMemo不重新计算 → 页面继续显示旧筛选结果正确依赖应为const filteredUsers useMemo(() { return users.filter( user user.status selectedStatus ); }, [users, selectedStatus]);原则仍然一样Memo逻辑读取了什么可变值就需要考虑把什么放进依赖。八、什么时候适合用useRef保存最新值有些场景确实不希望重新创建副作用但又需要访问最新状态。例如一个 WebSocket 连接组件创建 → 建立一次连接 → 后续消息处理需要读取最新用户配置如果每次配置变化都断开再重连可能没有必要。可以使用useRefconst configRef useRef(config); useEffect(() { configRef.current config; }, [config]);然后稳定的回调读取useEffect(() { socket.onmessage message { handleMessage( message, configRef.current ); }; return () { socket.close(); }; }, []);这样连接只建立一次但configRef.current始终指向最新值。适合WebSocket定时器DOM事件监听长生命周期第三方SDK不希望频繁重建的订阅。但不要为了逃避依赖数组把所有 state 都塞进 ref。九、事件监听特别容易出现旧闭包例如useEffect(() { function handleKeyDown(event: KeyboardEvent) { if ( event.key Enter keyword ) { search(keyword); } } window.addEventListener( keydown, handleKeyDown ); return () { window.removeEventListener( keydown, handleKeyDown ); }; }, []);如果keyword第一次是空字符串后面用户输入codex按回车时监听函数仍可能读到keyword 可以选择}, [keyword]);让监听随关键词更新。或者用 ref 保持监听函数稳定。关键不是哪种写法一定更好而是你必须明确事件处理函数需要的是“创建时的数据”还是“执行时的最新数据”。十、异步函数也会保存旧参数例如useEffect(() { async function load() { const result await search(keyword); setResults(result); } load(); }, []);如果keyword变化这个 Effect 不会重新运行。通常应该useEffect(() { async function load() { const result await search(keyword); setResults(result); } load(); }, [keyword]);如果再考虑前面讲过的竞态条件还需要配合AbortController 请求序号避免旧请求覆盖新请求。也就是说依赖数组解决的是“会不会因为状态变化重新发起任务”。请求隔离解决的是“旧任务返回后能不能覆盖新结果”。这是两个不同问题。十一、不要把Effect当成万能同步工具一个常见写法const [fullName, setFullName] useState(); useEffect(() { setFullName( ${firstName} ${lastName} ); }, [firstName, lastName]);实际上fullName完全可以直接计算const fullName ${firstName} ${lastName};如果为了同步状态不断增加 Effect就会出现state A变化 → Effect → 更新state B → 又触发其他Effect → 更新state C最后形成“Effect链”。Codex 在重构状态管理时尤其容易出现这种情况。能直接计算的派生数据优先直接计算而不是通过 Effect 再保存一份。十二、先区分Effect到底在做什么可以将 Effect 大致分成几类。数据请求userId变化 → 重新请求用户外部订阅组件挂载 → 监听WebSocketDOM或浏览器事件监听resize 监听keydown第三方系统同步播放器 地图SDK 编辑器如果一个 Effect 只是state变化 → 设置另一个可以计算出来的state通常值得重新考虑是否真的需要 Effect。十三、让Codex先做Hooks依赖审查遇到旧状态问题时可以先要求请先不要修改代码。 检查当前组件中的 - useEffect - useCallback - useMemo 对每一个Hook输出 1. 内部读取了哪些外部变量 2. 当前依赖数组是什么 3. 是否存在遗漏依赖 4. 是否存在不必要依赖 5. 是否可能产生stale closure 6. 是否可以改为函数式更新 7. 是否更适合使用ref。这样比直接说修复React状态不同步。更容易定位真正问题。十四、测试必须模拟状态变化只测试组件第一次渲染是不够的。例如初始keyword codex → 测试通过还应该验证keyword codex ↓ 用户修改为 chatgpt ↓ 触发事件 ↓ 回调必须使用 chatgpt可以重点覆盖props变化state变化定时器键盘事件路由参数变化异步请求组件卸载。Stale Closure 通常只有在“第一次渲染之后”才会暴露。十五、把Hooks规则写进AGENTS.md可以加入# React Hooks规则 - 不允许为了消除lint警告随意删除依赖 - 禁止无理由关闭react-hooks/exhaustive-deps - Hook读取的动态值必须检查依赖关系 - 基于旧state更新时优先使用函数式更新 - 长生命周期事件需要评估stale closure - 不希望重新订阅时可评估useRef保存最新值 - 可直接计算的派生状态不要使用Effect同步 - 修复Hooks问题后必须测试状态变化场景这样 Codex 在修改 Hooks 时会更关注闭包和生命周期而不是只追求代码“能跑”。十六、Plus还是Pro如果主要是单组件Hooks 普通useEffect问题 小型React项目 少量状态BugPlus 通常已经足够。如果项目中存在大型React仓库 大量自定义Hooks 复杂状态联动 长生命周期订阅 大量测试与重构则可以根据实际开发强度评估 Pro。不过无论使用哪个版本Hooks 的核心规则都一样函数拿到的是创建那一刻的变量还是执行那一刻的最新值这个问题必须在代码设计阶段明确。总结Codex 写 React Hooks 时总拿到旧状态很多时候并不是 React 更新失败而是 JavaScript 闭包保存了函数创建时的数据。通过正确维护依赖数组、使用函数式更新、合理使用useRef并减少不必要的 Effect 状态同步可以大幅降低 Stale Closure 问题。真正需要关注的不是这个Hook执行了吗而是它执行时拿到的到底是不是当前最新的数据CSDN文章描述本文介绍 Codex 编写 React Hooks 时常见的 Stale Closure 问题通过 useEffect、useCallback、useMemo 依赖数组、函数式更新和 useRef解决回调获取旧状态与数据不同步问题。