React中异步JavaScript API调用异常行为：成功请求先触发失败逻辑

出现「先打印failure再打印success」的表现，本质是fetchAppData被连续触发了两次执行：第一次执行时拿到的返回值中appDataResult.success为false，走了失败分支；第二次执行时拿到正确返回值，走了成功分支。对应的遗漏点主要有3个：

• 没有适配React 18严格模式下的副作用双执行逻辑
  开发环境下如果组件被React.StrictMode包裹，useEffect会在组件挂载时连续执行两轮：第一轮跑副作用逻辑、立刻执行清理函数、再跑第二轮副作用逻辑。如果你的接口调用没有配套的清理逻辑，就会同时发出两个请求：第一轮请求因为挂载初期的上下文缺失（比如身份参数、合约调用上下文没完全初始化），返回的success为false，触发failure日志；第二轮请求在上下文就绪后发出，拿到正确的成功返回，触发success日志。因为没有拦截旧请求的返回，两个结果都会正常走分支判断，最终出现日志时序错乱。
• 没有拦截依赖项的初始过渡态带来的无效请求
  当前useEffect的触发判断只校验了isLoggedIn和isSelectedAsset的真假，没有校验值的实际有效性：比如组件刚挂载时，两个状态的初始占位值可能短暂满足判断条件（比如isLoggedIn初始默认设为true、isSelectedAsset初始传入一个空占位对象），此时就会发出第一次无效请求，因为参数不全拿到失败返回打出failure日志；等状态更新为真实的登录结果、有效资产对象后，依赖变化再次触发请求，拿到正确结果打出success日志。
• 没有处理异步请求的竞态冲突
  当前fetchAppData没有做请求有效性标记，只要是接口返回的结果就会直接走分支判断。哪怕同一个触发逻辑下并发发出了两个请求，只要先返回的是失败结果、后返回的是成功结果，就会完全复现你描述的日志顺序问题，同时还会把旧的错误结果更新到应用状态里，直接影响核心业务逻辑。

额外补充：如果接口本身在刚发起时会先返回一个success: false的占位值，等真正的链上调用完成后再返回真实结果，也会出现同样的时序问题，本质和没有做请求状态锁定的逻辑缺失是一致的。

内容的提问来源于stack exchange，提问作者flow24