如何基于Promise同时返回即时结果与异步最终结果？

这种“先拿到临时ID给用户反馈，再等后端推送最终结果”的场景太常见了，用回调确实有点别扭，完全可以用更优雅的Promise风格方案来处理，我给你分享几个实用的思路：

方案一：返回包含即时值与结果Promise的对象 #

这其实是最直观的方案，虽然看起来“打破了单一Promise流”，但逻辑非常清晰，完全符合JS的语法习惯。你可以让函数直接返回一个对象，其中包含立即可用的jobId，以及一个会在推送结果到达时resolve的finalResult Promise。

示例代码如下：

function handleAsync(payload) {
  // 先发起POST请求获取jobId
  const postPromise = callAPI(payload);

  // 创建一个用于等待推送结果的Promise
  const finalResultPromise = new Promise((resolve, reject) => {
    // 这里注册WebSocket/Pusher的监听逻辑
    // 注意要在合适的时机移除监听，避免内存泄漏
    const handlePush = (eventData) => {
      if (eventData.jobId === postPromise.jobId) {
        if (eventData.success) {
          resolve(eventData.result);
        } else {
          reject(new Error(eventData.error));
        }
        // 移除监听
        pusher.unsubscribe('job-updates');
      }
    };
    pusher.subscribe('job-updates').bind('job-complete', handlePush);
  });

  // 等待POST请求完成后，返回包含jobId和结果Promise的对象
  return postPromise.then(response => ({
    jobId: response.jobId,
    finalResult: finalResultPromise
  }));
}

// 使用方式
handleAsync(myPayload).then(({ jobId, finalResult }) => {
  // 立刻通知用户
  alert(`任务已启动，ID：${jobId}`);
  // 等待最终结果
  return finalResult;
}).then(finalData => {
  console.log('最终结果:', finalData);
}).catch(err => {
  console.error('出错了:', err);
});

这种方式的好处是职责分明：用户可以第一时间拿到jobId做反馈，然后通过finalResult Promise优雅地等待最终结果，完全符合Promise的异步处理逻辑。

方案二：自定义带通知回调的Promise（进阶） #

如果你实在不想拆分返回值，也可以封装一个带有onJobIdReady回调的Promise。不过本质上和你原来的回调思路类似，但包装得更贴合Promise的用法：

function handleAsync(payload, onJobIdReady) {
  return new Promise((resolve, reject) => {
    callAPI(payload).then(response => {
      if (response.jobId) {
        // 触发通知回调
        onJobIdReady(response.jobId);
        // 注册推送监听
        const handlePush = (eventData) => {
          if (eventData.jobId === response.jobId) {
            eventData.success ? resolve(eventData.result) : reject(new Error(eventData.error));
            pusher.unsubscribe('job-updates');
          }
        };
        pusher.subscribe('job-updates').bind('job-complete', handlePush);
      } else {
        reject(new Error('未获取到任务ID'));
      }
    }).catch(reject);
  });
}

// 使用方式
handleAsync(myPayload, (jobId) => {
  alert(`任务已启动，ID：${jobId}`);
}).then(finalData => {
  console.log('最终结果:', finalData);
}).catch(err => {
  console.error('出错了:', err);
});

这种方式保持了单一Promise的返回流，同时用可选的回调来传递即时的jobId，比你原来的写法更规整，也避免了“回调嵌套”的问题。

总结 #

其实这两种方案都比单纯的回调要优雅：

• 如果希望代码结构更清晰、职责更分离，优先选方案一，它是现代JS中处理这类“多阶段异步”场景的常用模式；
• 如果更在意保持单一Promise的链式调用体验，方案二是不错的折中选择。

回调本身不是“hack”，但用Promise化的结构能让代码更易读、更符合异步编程的最佳实践~

内容来源于stack exchange