Firebase如何扩展FirebaseError？云函数自定义异常是否符合最佳实践？

问题1：是否可以扩展FirebaseError？ #

绝大多数场景下不建议也很难直接扩展，核心原因有两个：

• FirebaseError的构造函数并没有作为SDK的公开API对外导出，官方文档也没有相关继承说明，不同版本SDK的内部实现、暴露规则都可能变化，直接继承会有严重的版本兼容风险。
• 很多Firebase SDK的错误实例内置了私有标记（比如Symbol类型的内部标识位）用来校验错误类型，自行继承的子类就算复刻了code、message等属性，也过不了SDK内部的instanceof FirebaseError检查，实际使用会出现预期外的问题。
  你自己实现独立的AuthError子类反而是更稳妥的方案。

问题2：自定义异常处理是否属于不良实践？是否应该直接抛出HttpsError？ #

这反而是更合理的实践，完全不需要改成直接抛HttpsError。
核心逻辑是：你的signUpValidation属于业务验证模块，本来就不应该和Cloud Function的HTTP传输层逻辑耦合。如果直接在验证层抛HttpsError，等于把HTTP层的逻辑侵入到了业务逻辑中，后续你如果想把这套验证逻辑复用到非HTTP触发的Cloud Function（比如Pub/Sub触发、定时触发等场景），或者迁移到其他服务端框架，都要大量修改代码。
你当前的实现完全符合分层原则：

• 业务层（验证模块）只抛出业务相关的自定义AuthError，不关心上层使用什么传输协议
• 上层的Cloud Function入口层统一捕获所有业务错误，转换为对应的HttpsError返回给客户端
  你只需要在现有catch逻辑中新增一个AuthError的判断分支即可：

try {
  await validateSignUpData(
     username,
     email,
     password,
     repeatPassword,
     name,
     birthday,
     clientIp
  );
} catch(err) {
    if (err instanceof functions.https.HttpsError) {
      throw err;
    }
    // 新增自定义AuthError转换逻辑
    if (err.name === "AuthError") {
      // 可根据业务错误码映射对应的HttpsError状态码
      const httpCodeMap = {
        "auth/invalid-username": "invalid-argument",
        "auth/email-already-exists": "already-exists",
        // 其余错误码自行补充映射
      }
      throw new functions.https.HttpsError(
        httpCodeMap[err.code] ?? "invalid-argument",
        err.message,
        {
          status: "error",
          code: err.code,
          message: err.message
        }
      )
    }

    // 未知错误处理保持原有逻辑即可
    console.error(err);

    throw new functions.https.HttpsError(
      "unknown",
      "Unexpected error.",
      { 
        status: "error",
        code: err.code ?? "unknown",
        message: err.message ?? "The registration request could not be processed. Please, try again later."
      }
    );
}

这种实现解耦了业务逻辑和传输层，可维护性、可复用性都远高于直接在验证层抛HttpsError的方案。

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