TypeScript后端JWT开发冗余try-catch优化方案咨询

原分散式多try-catch写法的缺陷 #

• 冗余只是表象，本质问题是完全丢失原始错误上下文：每个catch块无差别捕获所有错误后直接替换成自定义错误，原始错误的栈轨迹、具体原因全部被丢弃，线上排查根因时根本没法定位底层到底是数据库断连、JWT库抛的验签异常，还是其他运行时问题
• 流程割裂：读代码时需要在正常业务流程和异常分支之间反复跳转，阅读成本远高于顺序执行的逻辑

你提出的“内部吞错返回空值”方案的缺陷 #

这个思路的问题比原写法更严重：

• 语义歧义：返回空值没法区分“逻辑正常但结果为空”和“函数运行时崩了”两类完全不同的场景，比如查询用户返回null，到底是用户本来不存在，还是函数内部数据库连接报错被catch后返回空，外层逻辑完全没法判断
• 破坏TypeScript类型安全：所有返回值需要额外处理空值分支，很容易出现漏判空值导致的下游运行时崩溃
• 同样丢失错误上下文：函数内部catch原始错误后不抛出直接返回空，等外层判断为空抛自定义错误时，原始的错误栈已经全部丢失，完全失去排查线索

核心思路是分层错误处理，不做无意义的重复catch，让错误自然向上冒泡：

1. 先设计统一的自定义错误基类，从根源上解决错误识别和上下文保留的问题

   // 自定义错误基类
   class AppError extends Error {
     constructor(
       public httpStatus: number,
       public errorCode: string,
       message: string,
       public cause?: unknown
     ) {
       super(message);
       Error.captureStackTrace(this, this.constructor);
     }
   }
   
   // 具体业务错误类
   class UserNotFoundError extends AppError {
     constructor() {
       super(404, "USER_NOT_EXIST", "请求关联的用户不存在");
     }
   }
   class InvalidTokenError extends AppError {
     constructor(cause?: unknown) {
       super(401, "TOKEN_INVALID", "JWT令牌校验不通过", cause);
     }
   }
   

2. 业务函数层按规则抛错，不随意吞错
   不要在每个业务函数内部无差别catch所有错误：
   • 遇到明确的业务异常场景（比如查不到用户、token格式不对），直接抛出对应的自定义错误
   • 遇到需要映射的第三方库错误（比如JWT验签失败），只捕获这一类特定错误，映射成自定义错误时把原始错误挂在cause字段上保留上下文
   • 遇到非预期的运行时错误（比如数据库断连），不要catch，让错误自动向上冒泡
3. 业务流程按顺序书写，不需要每一步单独包try-catch
   原来需要写N个try块的逻辑，完全可以改成顺序执行的代码，让错误自然向上传递：

   async function jwtAuthMiddleware(req: Request, res: Response, next: NextFunction) {
     // 步骤1：提取请求头的token，缺失直接抛错
     const token = extractBearerToken(req.headers.authorization);
     if (!token) throw new InvalidTokenError();
   
     // 步骤2：验签，验签逻辑内部遇到格式错误直接抛自定义错误
     const payload = verifyJwtToken(token);
   
     // 步骤3：查询对应用户，不存在直接抛错
     const user = await queryUserById(payload.sub);
     if (!user) throw new UserNotFoundError();
   
     // 流程正常，把用户信息挂载到请求对象上往下走
     req.user = user;
     next();
   }
   

4. 全局统一兜底错误处理
   服务端只需要在所有路由注册完成后，加一个全局错误处理中间件，接住所有向上抛的错误，统一格式化返回给客户端，不需要在每个业务步骤外重复写catch逻辑：

   // 全局错误中间件
   app.use((err: unknown, req: Request, res: Response, next: NextFunction) => {
     // 识别自定义业务错误，按预设规则返回
     if (err instanceof AppError) {
       return res.status(err.httpStatus).json({
         code: err.errorCode,
         message: err.message,
       });
     }
     // 非预期错误统一落日志，返回通用提示
     console.error("未处理异常:", err);
     res.status(500).json({
       code: "INTERNAL_SERVER_ERROR",
       message: "服务内部异常",
     });
   });
   

核心原则：错误处理不需要“每一步都拦住”，而是要让每个环节把该抛的错误抛对，在最靠近出口的位置统一接住。重复的try-catch除了增加代码冗余，最大的危害是破坏错误栈的完整性，大幅提升线上问题的排查成本。

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