是否每个db查询需包裹try/catch？同一async函数多查询单独捕获还是共用？

两种实现没有绝对的对错，也不存在“行业通用最佳实践”的标准答案，选型的核心完全围绕业务流程的依赖关系、错误处理的粒度需求、代码维护成本三个维度判断。

独立try/catch块的实现方式 #

这类写法的典型代码结构如下：

const confirmEmailVerification = async (req, res) => {
  const { token } = req.body;
  let user;
  try {
    const result = await db.query(
      'SELECT user_account_id FROM user_account WHERE email_verification_token = $1',
      [token]
    );
    if (result.rows.length === 0) {
      return res
        .status(400)
        .json('Please verify your account by clicking the link in your email');
    }
    user = result.rows[0].user_account_id;
  } catch (err) {
    console.error(err.message);
    return res.status(500).json('Server Error');
  }

  try {
    const active = await db.query(
      'UPDATE user_account SET email_verified = TRUE WHERE user_account_id = $1',
      [user]
    );
    return res.status(200).json({
      message: 'Email has been verified, Please login',
    });
  } catch (err) {
    console.error(err.message);
    return res.status(500).json('Server Error');
  }
};

这种写法的设计依据和适用场景包括：

• 核心逻辑是把每个DB查询当成独立的、可单独失败的业务单元，单步异常不阻断其他步骤的合理执行
• 适用于多个DB查询之间没有强顺序依赖的场景：比如接口需要同时查询用户基础信息、加载首页运营banner，两个查询互不依赖，就算banner查询超时，也不能影响用户信息的正常返回，这时候就需要给每个查询单独包try/catch，捕获到banner查询错误时返回兜底的空banner数据，而不是让整个接口报错
• 适用于需要针对不同查询的异常返回差异化错误提示的场景：比如查询用户权限失败要返回“账号权限校验失效，请重新登录”，更新用户操作日志失败仅需要静默记日志、不影响核心流程的返回，这种场景下独立catch才能做到针对性处理
• 适用于单步失败后需要基于前序结果做降级或补偿的场景：比如先查询出用户的已购商品列表，后续推荐位查询超时失败，这时候可以单独捕获推荐位的错误，直接返回已加载完成的已购商品列表，不用让整个接口因为推荐模块的问题挂掉

针对上面示例里的邮箱验证逻辑，这种拆分写法其实存在明显冗余：两个catch块里的日志打印、500响应逻辑完全一致，拆分出来只是多写了一遍重复代码，没有实际的业务收益。

共用try/catch块的实现方式 #

这类写法的典型代码结构如下：

const confirmEmailVerification = async (req, res) => {
  const { token } = req.body;
  let user;
  try {
    const result = await db.query(
      'SELECT user_account_id FROM user_account WHERE email_verification_token = $1',
      [token]
    );
    if (result.rows.length === 0) {
      return res
        .status(400)
        .json('Please verify your account by clicking the link in your email');
    }
    user = result.rows[0].user_account_id;

    const active = await db.query(
      'UPDATE user_account SET email_verified = TRUE WHERE user_account_id = $1',
      [user]
    );
    return res.status(200).json({
      message: 'Email has been verified, Please login',
    });
  } catch (err) {
    console.error(err.message);
    return res.status(500).json('Server Error');
  }
};

这种写法的设计依据和适用场景包括：

• 核心逻辑是把同个业务链路里的关联查询当成一个整体，任意一步失败就终止整个流程的执行
• 适用于查询间存在强顺序依赖的场景：就像示例中的邮箱验证流程，必须先通过token查到有效用户ID，才能执行更新用户验证状态的操作，没有查到有效用户的话UPDATE语句根本没有执行的参数，两个步骤的成功是强绑定的，只要任意一步出错，整个验证流程就没法完成，自然不需要拆分独立捕获
• 适用于所有查询的异常处理逻辑完全统一的场景：不管是SELECT语句的执行错误、还是UPDATE语句的连接超时，本质都是数据库层面的通用故障，不需要针对SQL类型做区分，统一返回500错误、打印统一格式的错误日志即可，这种场景下共用try/catch能大幅减少重复代码
• 适用于涉及数据库事务的操作：比如账户转账、订单状态更新这类需要原子性保证的操作，多个查询本来就需要放在同一个事务块里执行，任意一步出错都要整体回滚，把所有查询包在同一个try/catch里，可以直接在catch块里执行事务回滚逻辑，比拆分独立块的流程顺畅很多

快速选型判断标准 #

• 如果两个DB查询之间需要依赖前一步的结果才能执行，且所有错误处理逻辑完全一致，就完全没必要拆独立try/catch
• 如果两个查询互不依赖、或者需要对不同步骤的错误做差异化处理，再拆成独立块更合理
• 开发中很容易踩两个极端的坑：
  • 为了追求“代码严谨感”，把所有DB操作都拆成独立try/catch，结果每个catch里的日志逻辑、响应逻辑完全一模一样，代码篇幅翻了一倍，后期改错误处理逻辑要同步改好几个地方，平白增加维护成本
  • 反过来图省事，把完全独立的非核心查询和核心查询全塞到同一个try块里，结果非核心的查询因为超时崩了，连带已经执行成功的核心查询结果也没法正常返回，平白降低了接口的可用性

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