Express+PostgreSQL开发：数据库请求前是否需做类型检查？

我正在学习如何在Express框架中结合PostgreSQL数据库正确处理错误。我有多个作为中间层的后端小函数，用于在更大的函数中与数据库交互。我纠结于两种方案：一是在发送数据库请求前先做类型检查（如示例#1），二是直接发送请求并处理数据库返回的错误（如示例#2）。前者存在重复代码的问题，后者可能丢失错误的具体信息，想知道哪种方案在多数情况下更适用，以及是否有其他常见处理方式。

// #1 请求前做类型检查
export const getPerson = ({
  emailAddress,
  personID,
}: {
  emailAddress?: string;
  personID?: string;
}) => {
   // BadRequestError 是继承自 Error 的自定义错误类
  if (!isString(emailAddress)) throw new BadRequestError(); 
  if (!isUUID(personID)) throw new BadRequestError();
  return pool
    .query(
      `SELECT
        *
      FROM person
      WHERE ($1::citext IS NULL OR person.emailAddress = $1)
        AND ($2::uuid IS NULL OR person.person_id = $2)` ,
      [emailAddress, personID]
    )
    .then((res) => res.rows)
    .catch(() => { throw new InternalServerError(); })
  };

// #2 不做前置类型检查，直接返回 pool.then().catch()
// 我觉得这种更简洁，但可能无法知道哪个输入不正确，而且会给数据库发送无效请求

export const getPerson = ({
  emailAddress,
  personID,
}: {
  emailAddress?: string;
  personID?: string;
}) => pool
    .query(
      `SELECT
        *
      FROM person
      WHERE ($1::citext IS NULL OR person.emailAddress = $1)
        AND ($2::uuid IS NULL OR person.person_id = $2)` ,
      [emailAddress, personID]
    )
    .then((res) => res.rows)
    .catch((e) => { 
      switch (e.code) {
         case '23XXX':
            throw new BadRequestError();
      }
    }
 );

方案对比与适用场景 #

1. 前置类型检查（方案#1） #

• 优势：
  • 提前拦截无效输入，避免给数据库发送不必要的请求，减轻数据库负载。
  • 可以精准定位错误字段，返回更友好的错误信息（比如针对emailAddress和personID分别抛出带具体提示的BadRequestError，而非统一错误）。
• 劣势：
  • 重复代码：多个函数都要写类似的类型校验逻辑，容易产生冗余。
• 适用场景：
  • 输入校验逻辑简单且高频复用的场景；
  • 对数据库资源占用敏感的系统；
  • 需要给前端返回精准错误提示的场景。

2. 依赖数据库错误处理（方案#2） #

• 优势：
  • 代码更简洁，无需重复编写校验逻辑；
  • 利用数据库的原生约束（如UUID类型、citext类型）做校验，避免前端校验与数据库约束不一致的问题。
• 劣势：
  • 无法直接定位具体错误字段：PostgreSQL返回的23XXX类约束错误只能说明输入不符合类型，但无法区分是emailAddress还是personID出问题；
  • 会产生无效数据库请求，单条请求开销虽小，但高并发下可能累积性能损耗。
• 适用场景：
  • 校验逻辑复杂，与数据库约束强绑定的场景；
  • 快速开发原型，对错误提示精度要求不高的阶段。

更优的折中方案 #

解决重复代码和错误信息缺失的问题，常见的两种优化方式如下：

a. 封装通用校验函数 #

把重复的校验逻辑抽成可复用的工具函数，兼顾代码简洁性和错误提示精准性：

// 通用校验工具函数
export const validatePersonQueryParams = ({ emailAddress, personID }) => {
  const errors = [];
  if (emailAddress && !isString(emailAddress)) {
    errors.push('邮箱地址格式错误');
  }
  if (personID && !isUUID(personID)) {
    errors.push('用户ID格式错误');
  }
  if (errors.length > 0) {
    throw new BadRequestError(errors.join('; '));
  }
};

// 业务函数中使用校验
export const getPerson = ({ emailAddress, personID }) => {
  validatePersonQueryParams({ emailAddress, personID });
  return pool.query(...)
    .then(res => res.rows)
    .catch(e => {
      // 兜底处理数据库约束类错误
      if (e.code.startsWith('2')) {
        throw new BadRequestError('输入参数不符合要求');
      }
      throw new InternalServerError();
    });
};

这种方式既避免了重复代码，又能精准给出错误提示，同时保留数据库作为最后一道校验防线。

b. 解析数据库错误消息定位问题 #

利用PostgreSQL错误的具体信息，从返回的错误消息中提取字段问题：

.catch((e) => {
  if (e.code === '22P02') { // 无效文本格式错误
    if (e.message.includes('uuid')) {
      throw new BadRequestError('用户ID格式错误');
    } else if (e.message.includes('citext')) {
      throw new BadRequestError('邮箱地址格式错误');
    }
  } else if (e.code.startsWith('23')) { // 约束违反错误
    throw new BadRequestError('输入参数不符合约束');
  }
  throw new InternalServerError();
});

这种方式无需前置校验，通过解析错误消息定位问题字段，但依赖PostgreSQL错误消息的格式，需要注意兼容性。

总结 #

多数生产环境下，封装通用校验函数的折中方案是最优选择：既保证错误提示的精准性，又避免重复代码，同时数据库约束作为最后一道防线，防止前端校验遗漏的情况。如果是快速开发阶段，可以先用方案#2，后续再补充校验逻辑。

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