Express开发中不等待特定Promise执行完成是否为错误写法？

你想让埋点写入后台运行、不阻塞主响应的思路完全合理，不await本身不是写法错误，但你当前的实现缺少必要的错误兜底，才会出现报错被覆盖、日志排查困难的问题。

你看到的报错本质是多个问题叠加导致的：

• 你没有为insertInsightsEventIntoDatabase()返回的Promise添加catch处理，当埋点写入逻辑抛出ORM错误时，这个rejection会直接冒泡到Node.js全局，触发Express的兜底错误处理逻辑
• 这时候你已经执行return data把核心业务响应返回给客户端了，响应头已经发送完成，Express的兜底错误处理再尝试向客户端返回500错误时，就会触发Cannot set headers after they are sent to the client的二次错误，把原本的ORM原始报错完全覆盖，所以你看不到有效排查信息
• 你加了await之后能看到清晰ORM报错的原因也很简单：await会把Promise的rejection直接抛到当前路由处理函数的执行上下文里，这时候还没执行return发送响应，错误可以被正常捕获打印，不会触发二次报错，但代价就是埋点写入会阻塞主流程响应，和你的需求相悖。

非核心旁路任务用fire-and-forget（触发后不等待）模式完全合法，只需要给这类后台Promise单独加错误捕获，不要让错误冒泡到请求响应链路即可：

const data = await getResponseDataFromDatabase();

// 后台执行埋点写入，不await阻塞响应
insertInsightsEventIntoDatabase()
  .catch(err => {
    // 单独记录埋点错误日志，不要向上抛出错误
    console.error('埋点事件写入失败', err);
    // 此处不需要做任何影响主流程的操作，埋点失败不返回给用户
  });

return data;

• 确保insertInsightsEventIntoDatabase函数内部不要操作Express的res响应对象，不要在这个函数里写任何修改响应状态、返回内容的逻辑，它应该是完全独立的副作用操作
• 如果服务QPS较高，直接在请求链路里起异步写库操作可能会占用数据库连接、阻塞事件循环，埋点类场景建议优先用批量攒写、消息队列削峰的方式实现，稳定性更高
• 从Node.js v15开始，未处理的Promise rejection会直接导致进程崩溃，哪怕是旁路任务的Promise也必须显式加catch处理，否则会有服务宕机风险

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