使用 Codex 修改前端项目时有一类 Bug 很难在第一次测试中发现页面功能看起来正常接口也没有报错但用户连续操作几次后界面却显示了错误的数据。常见表现包括用户快速切换两个账号最后显示的却是第一个账号资料搜索框连续输入旧关键词结果覆盖新关键词切换页面后之前的请求返回并修改当前页面状态点击两次保存较早的请求最后返回把最新状态覆盖掉Loading 状态提前结束网络越慢问题越容易出现。这类问题通常不是接口错误而是典型的Race Condition竞态条件。一、为什么异步请求会发生状态覆盖看一个很常见的代码async function loadUser(userId: string) { setLoading(true); const user await api.getUser(userId); setUser(user); setLoading(false); }用户先点击用户AloadUser(A)随后马上点击用户BloadUser(B)理论上界面应该显示B。但网络请求返回顺序不一定与发送顺序相同。可能发生请求A发送 ↓ 请求B发送 ↓ 请求B返回 ↓ 界面显示B ↓ 请求A较晚返回 ↓ 界面又被覆盖成A代码每一行都没有语法错误但最终状态已经错了。这就是典型的竞态问题。二、为什么Codex容易生成这种代码因为从单次调用来看const result await request(); setState(result);完全合理。Codex 如果只看到根据userId获取用户信息并更新页面。它通常会优先完成正常流程。但真实用户可能快速切换重复点击返回上一页网络卡顿同时触发多个请求。所以对于异步逻辑不能只问请求成功以后做什么还要问请求回来时这个结果还有效吗三、最简单的方法使用请求序号可以给每一次请求增加编号let latestRequestId 0; async function loadUser(userId: string) { const requestId latestRequestId; setLoading(true); const user await api.getUser(userId); if (requestId ! latestRequestId) { return; } setUser(user); setLoading(false); }执行过程变成请求ArequestId 1 请求BrequestId 2如果A最后才返回1 ! 2结果直接丢弃。这样可以确保只有最后一次请求可以修改当前页面状态。这种方式特别适合搜索建议用户详情切换Tab切换筛选条件变化分页查询。四、能取消就直接取消旧请求如果请求支持取消更推荐在新任务开始时终止旧请求。浏览器中可以使用AbortControllerlet controller: AbortController | null null; async function loadUser(userId: string) { controller?.abort(); controller new AbortController(); try { const user await fetch( /api/users/${userId}, { signal: controller.signal } ).then(res res.json()); setUser(user); } catch (error) { if ( error instanceof DOMException error.name AbortError ) { return; } throw error; } }每次新请求开始取消旧请求 → 创建新请求 → 只等待最新结果好处不仅是避免状态覆盖还能减少无意义的网络请求。五、组件销毁后不要继续更新状态另一个常见问题是打开页面 → 请求开始 → 用户离开页面 → 请求返回 → 继续修改已经失效的页面状态React 中可以配合清理函数useEffect(() { const controller new AbortController(); loadData(controller.signal); return () { controller.abort(); }; }, []);Vue 中也可以在组件卸载时终止未完成请求。原则是页面生命周期结束对应异步任务也应该失效。不要让已经离开的页面继续影响当前状态。六、Loading状态也会发生竞态很多代码会写setLoading(true); await request(); setLoading(false);如果同时存在两个请求请求A开始 请求B开始 请求A先结束A执行setLoading(false);但此时B还没完成。用户就会看到 Loading 消失但后台仍在加载。更稳妥的方法可以记录请求数量let pendingCount 0; async function runRequest() { pendingCount; setLoading(true); try { await request(); } finally { pendingCount--; if (pendingCount 0) { setLoading(false); } } }或者直接让每个独立模块管理自己的请求状态。不要让多个不相关请求共享一个简单的loading: boolean七、搜索框是最容易出现竞态的地方例如用户输入c co cod code codex如果每次输入都请求watch(keyword, async value { results.value await search(value); });网络返回顺序可能是codex code cod最后页面显示的反而是cod的结果。这种场景通常应该同时使用防抖减少请求数量300ms内连续输入 → 不请求 停止输入300ms → 再请求请求隔离即使旧请求已经发出也不能覆盖新结果。防抖解决“请求太多”请求隔离解决“结果顺序错误”。两者不是一回事。八、不要使用全局变量保存所有异步状态Codex 有时为了快速解决问题会把请求状态放到全局let currentUserRequest; let loading; let currentResult;小项目可能暂时可用但随着页面增加很容易互相干扰。更合理的方式是让状态与任务作用域绑定用户模块 → 用户请求状态 订单模块 → 订单请求状态 搜索模块 → 搜索请求状态如果使用 React Query、TanStack Query、SWR 等数据请求工具也应该利用其请求键和缓存机制而不是继续手动维护一套全局异步状态。九、保存操作不能简单使用“最后返回覆盖”读取数据可以丢弃旧结果但写操作需要更加谨慎。例如用户快速点击两次保存保存Aname Tom 保存Bname Jerry如果服务器最终处理顺序变成B → A数据库最后可能保存成Tom。这时前端取消请求并不能保证服务器停止执行。写操作通常需要结合防止重复提交请求幂等版本号乐观锁服务端状态校验。例如version 5更新时要求UPDATE users SET name ?, version 6 WHERE id ? AND version 5;如果另一请求已经修改版本号当前更新就会失败而不是静默覆盖新数据。十、用状态机管理复杂异步流程如果流程已经包含idle loading success error retrying cancelled继续堆叠isLoading isError isRetrying isCancelled很容易出现互相矛盾的状态。例如isLoading true isError true此时页面到底应该显示加载中还是错误可以明确使用状态type RequestStatus | idle | loading | success | error | cancelled;然后state.status loading;失败后state.status error;取消后state.status cancelled;复杂异步业务中明确状态转换比多个布尔值更加稳定。十一、让Codex先分析“谁可以更新状态”开始处理异步Bug时可以先这样问请先不要修改代码。 分析当前异步流程 1. 哪些函数会发起请求 2. 哪些请求可能同时执行 3. 哪些请求会更新同一个状态 4. 请求返回顺序是否可能变化 5. 旧结果是否可能覆盖新状态 6. 组件卸载后是否仍会更新状态。先把状态写入路径找出来再决定使用AbortController 请求序号 防抖 状态机 版本号不要一上来就大范围重构。十二、测试竞态不能只测试单次请求普通测试可能只是请求成功 → 页面显示数据还应该加入请求A开始 请求B开始 请求B先返回 请求A后返回最终必须验证页面仍然显示B还可以测试请求过程中切换页面连续点击两次旧请求被取消新请求失败组件卸载请求超时Loading状态是否正确。竞态问题如果没有模拟异常顺序很难真正覆盖。十三、把异步规则写进AGENTS.md可以加入# 异步请求规则 - 新请求必须评估旧请求是否仍然有效 - 搜索和切换类请求必须防止旧结果覆盖 - 支持取消的请求优先使用AbortController - 组件卸载后禁止继续更新页面状态 - 多请求不得共用不准确的loading布尔值 - 写操作必须评估重复提交与版本冲突 - 复杂异步流程优先使用明确状态机 - 修复竞态问题后必须增加乱序返回测试这样 Codex 后续生成异步代码时会更容易主动考虑状态生命周期。十四、一个推荐的异步任务检查流程可以固定为找到状态 ↓ 找到所有写入点 ↓ 找到所有异步请求 ↓ 判断是否可能并行 ↓ 模拟乱序返回 ↓ 选择取消 / 序号 / 版本控制 ↓ 增加测试 ↓ 再提交代码真正需要关注的不是Promise 有没有 await。而是await 结束以后这个结果还应该不应该生效十五、Plus还是Pro如果主要处理单页面请求搜索框用户详情切换少量异步Bug小型前端项目Plus通常可以覆盖多数Codex任务。如果长期维护大型前端、复杂状态管理、多请求并发、跨模块异步流程并且需要持续分析大量代码和测试则可以根据实际开发强度评估Pro。不过版本并不能自动消除竞态条件。异步状态是否正确最终仍取决于任务边界和状态设计。总结Codex写出的异步请求出现状态覆盖通常不是async/await写错而是代码默认认为请求返回顺序 请求发送顺序。真实网络并不保证这一点。通过请求序号、AbortController、防抖、状态机和服务端版本控制可以让旧任务失效让最新操作拥有明确的状态所有权。真正稳定的异步代码需要回答一个关键问题当这个请求终于返回时它还有资格修改当前状态吗CSDN文章描述本文介绍Codex编写前端异步请求时常见的竞态条件通过AbortController、请求序号、防抖、状态机和版本控制解决旧请求覆盖新状态、Loading异常和重复保存等问题。