Serverless（NextJS）环境下Fire and forget式Promise的最佳实践

首先直接给结论：可行，但不能用单纯的"fire and forget"，需要借助特定机制确保请求已发出，同时不阻塞主流程。下面是具体的实践方案：

1. 优先使用fetch的keepalive选项（推荐） #

Node.js 18+（NextJS 13+默认支持）的fetchAPI支持keepalive参数，开启后会让请求脱离当前函数的生命周期，即使NextJS准备终止进程，底层也会保证把请求发送出去，而且不需要等待响应。

示例代码：

// 上报日志的函数，无需await
async function sendLog(logData) {
  try {
    await fetch('第三方日志接口地址', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(logData),
      keepalive: true, // 关键配置
      signal: AbortSignal.timeout(5000) // 可选：设置超时，避免无意义的挂起
    });
  } catch (err) {
    // 这里可以做降级处理，比如把日志暂存到本地文件（服务器环境）
    console.error('日志上报失败:', err);
  }
}

// 主流程中调用，无需await
sendLog({ message: '用户登录', timestamp: Date.now() });

这个方案既不会阻塞主函数执行，又最大程度保证了请求能被发出，是目前最简洁可靠的方式。

2. 本地队列+批量上报 #

如果日志量较大，单条上报不仅效率低，还容易因为频繁请求被NextJS终止。可以用内存队列攒一批日志，定时或达到指定数量后批量发送：

示例代码（简单内存队列实现）：

const logQueue = [];
const MAX_QUEUE_SIZE = 20;
const FLUSH_INTERVAL = 5000; // 5秒批量发送一次

// 初始化定时任务
setInterval(() => {
  if (logQueue.length === 0) return;
  // 取出队列中的日志，批量发送
  const logs = [...logQueue];
  logQueue.length = 0;
  fetch('第三方日志接口地址', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(logs),
    keepalive: true
  }).catch(err => console.error('批量上报失败:', err));
}, FLUSH_INTERVAL);

function addLog(logData) {
  logQueue.push({ ...logData, timestamp: Date.now() });
  // 达到队列上限立即发送
  if (logQueue.length >= MAX_QUEUE_SIZE) {
    const logs = [...logQueue];
    logQueue.length = 0;
    fetch('第三方日志接口地址', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(logs),
      keepalive: true
    }).catch(err => console.error('批量上报失败:', err));
  }
}

// 主流程调用
addLog({ message: '用户浏览页面' });

这种方式既减少了请求次数，又降低了单条日志丢失的概率，同时对主流程的性能影响可以忽略不计。

3. 避免无效的等待（比如1ms延迟） #

你提到的每条日志后加1ms等待完全没必要，甚至可能起反作用：

• 1ms的时间无法保证请求已经完成发送，NextJS仍可能在事件循环的下一轮终止进程；
• 大量日志的话，累计等待时间反而会增加主流程的执行时长，违背了异步上报的初衷。

关于日志顺序的补充 #

如果业务需要严格保证日志的到达顺序，除了时间戳，还可以给每条日志加一个全局递增的序号，后端接收后可以根据序号排序；如果业务允许一定的乱序，时间戳已经足够满足需求。

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