无法将回调改为Promise时，如何在for循环中用async/await实现回调顺序执行

你现在遇到的「所有请求发完才统一执行回调」，根本不是async/await用错了，是uploadAPI自带的Promise逻辑，压根没有把「回调执行完成」当作自身Promise的结束判定条件——它现在的触发逻辑是只要把请求发出去、拿到响应就立刻把Promise置为成功状态，自然会导致循环里的await根本挡不住请求批量发起。
因为约束是不能修改uploadAPI本身的代码结构、不能把原有回调改写为Promise式的实现，所以不需要动uploadAPI的内部逻辑，只需要在你自己的循环调用层做一层薄适配就行。

• 给每一次upload调用手动包一层可控Promise，把这个Promise的resolve时机，严格绑定在原回调执行完成的节点上
• 每次循环用独立局部变量存储当前处理的文件，避免全局currentFile被后续循环覆盖，导致回调里打印的文件名错乱
• 完全保留原有uploadCallback、uploadAPI的入参和内部逻辑，不改动任何组织既定的代码结构

// 以下为完全不能修改的既定原有代码
uploadCallback = () => {
  console.log(currentFile)
}

// 以下为你可以调整的循环逻辑部分
const loop = async () => {
  for (let i = 0; i < this.state.fln.length; i++) {
    // 循环内局部变量存当前处理的文件对象
    const currentObj = this.state.fln[i]
    currentFile = currentObj // 适配原有回调依赖全局currentFile的逻辑，不改动回调本身

    // 包裹单次upload调用，让等待逻辑对齐回调执行完成的节点
    await new Promise((resolve) => {
      // 薄包裹原有回调，不改动回调内部任何逻辑
      const wrappedCallback = () => {
        this.uploadCallback()
        // 原回调执行完毕后立刻resolve，阻断后续循环执行
        resolve()
      }
      // 完全按照原有调用参数规则传参，不修改uploadAPI的入参签名
      uploadAPI(currentObj, wrappedCallback)
    })

    console.log('currentFile:', i, currentFile)
  }
}

改完之后的执行顺序会完全匹配预期：

1. 循环走到第i个文件，给全局currentFile赋值为当前文件对象
2. 按照原有规则发起uploadAPI调用，挂接包裹后的回调
3. 等到接口请求返回，触发包裹后的回调：先执行原有回调逻辑打印当前文件名，再触发Promise的resolve
4. 只有当Promise完成resolve后，才会进入下一次循环，处理第i+1个文件
   全程不会出现所有请求批量发起、回调统一执行的问题，且完全符合「不能改动既定代码结构、不能将回调改写为Promise原生形式」的约束。

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