基于Express的MVC后端：错误应抛在Service还是Controller？

我正在用Express构建MVC模式的后端，已经引入了express-async-errors和http-errors工具，能在任意位置抛出错误，由自定义中间件统一处理。现在纠结以下三种错误处理方案哪种更合理：

方案1：Service层直接抛出完整HTTP错误，Controller不写try/catch #

export default class UserService {
  public error(){
    throw createError(404,"Error Message")
  }
}

方案2：Service层抛出通用错误，Controller层转成HTTP错误 #

Service代码

export default class UserService {
  public error(){
    throw Error("Error Message")
  }
}

Controller代码

export default class UserController {
 public simpleMethod(){
  try {
    userService.error()
  } catch (error:any) {
    throw createError(404,error.message)
  }
 }
}

方案3：Service层返回含error属性的对象，Controller层处理逻辑 #

Service代码

export default class UserService {
  public error(){
    return {error:"Error Message"}
  }
}

Controller代码

export default class UserController {
  public simpleMethod() {
    const message = userService.error()
    if (message.error) {
      throw createError(404, message.error)
    }
  }
}

我原本觉得在Service层直接处理更优，能精准定义错误类型，但有人建议在Controller层处理，想知道哪种才是正确的处理方式？

分析与结论 #

方案1：适合单一HTTP场景的业务

• 优点：代码最简洁，不用在Controller层写重复的try/catch，Service层可直接根据业务逻辑精准定义HTTP状态码和错误信息，配合express-async-errors能自动把错误传递到全局中间件处理。
• 缺点：Service层耦合了HTTP相关逻辑（比如状态码），如果后续该Service需要被非HTTP场景调用（比如定时任务、CLI工具），HTTP状态码会失去意义，造成逻辑冗余。

方案2：适合需要复用Service的场景

• 优点：Service层只关注业务错误，完全解耦HTTP逻辑，通用性更强。Controller层作为HTTP入口，负责把业务错误转换成对应的HTTP响应格式，符合MVC职责划分（Controller处理请求/响应适配，Service处理业务逻辑）。如果需要，还可以自定义业务错误类（比如UserNotFoundError），让Controller能更精准判断错误类型并返回对应状态码。
• 缺点：若未利用express-async-errors的自动捕获特性，每个Controller方法都要写try/catch，代码会有冗余，但你已经用了express-async-errors，可简化为在全局中间件或Controller的统一处理逻辑中完成错误转换。

方案3：不推荐使用

• 优点：完全避免异常抛出，用返回值处理错误，对部分反感异常的开发者友好。
• 缺点：Controller层必须每次手动判断返回值里的error属性，容易遗漏；无法利用express-async-errors自动捕获异步错误的特性，代码繁琐，也不符合JS/TS用异常处理意外错误的常规做法，会增加维护成本。

最终建议 #

• 如果你的Service只服务于HTTP接口，方案1是最高效的选择，代码简洁且错误定义精准。
• 如果你的Service需要被非HTTP场景复用，方案2更合适，把业务逻辑和HTTP适配解耦，扩展性更好。

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