自定义异常应继承Exception而非BaseException，因后者包含SystemExit、KeyboardInterrupt等系统级异常，继承BaseException会导致无法被except Exception:捕获，并意外中断程序退出流程。
为什么要继承 Exception 而不是 BaseException
直接继承 BaseException 会导致你的异常无法被常规 except Exception: 捕获，可能意外中断程序——比如 sys.exit() 和 KeyboardInterrupt 就是 BaseException 的子类，Python 明确建议业务异常只继承 Exception。
自定义异常的核心目标是：让调用方能区分错误类型、提取结构化信息（如错误码），同时不破坏 Python 异常处理的默认行为。
__init__ 中必须显式接收并存储 error_code
不要依赖类属性或全局字典映射错误码，那会让实例失去独立性。每个异常实例应自带可读的错误码和消息。
常见错误是只存 message，后续靠字符串解析反推错误码，既脆弱又低效。
立即学习“Python免费学习笔记（深入）”；
- 在
__init__中强制要求error_code参数（可设默认值，但不推荐） - 把
error_code绑定到实例属性，例如self.error_code = error_code - 重写
__str__或__repr__，让打印时自然带出错误码，便于日志排查
class BizError(Exception):
def __init__(self, error_code: str, message: str):
super().__init__(message)
self.error_code = error_code
def __str__(self):
return f"[{self.error_code}] {super().__str__()}"
如何配合 HTTP 响应或日志统一处理 error_code
业务异常抛出后，通常需要转换为 API 返回的 JSON 结构（如 {"code": "USER_NOT_FOUND", "msg": "用户不存在"}），而不是裸奔异常信息。
关键点在于：不要在每个 except 块里重复构造响应体，而是集中拦截处理。
- FastAPI 中可用
@app.exception_handler(BizError)统一返回 JSON - Django 可在中间件中捕获
BizError并转为 JsonResponse - 日志记录时，优先输出
exc.error_code而非type(exc).__name__，方便 ELK 聚类分析
避免用字符串拼接错误码，用枚举或常量类管理
硬编码 "ORDER_TIMEOUT" 散落在各处，容易拼错、难搜索、无法 IDE 跳转。上线后改一个错误码要 grep 全局，风险高。
更稳妥的做法是定义一个错误码中心：
- 用
Enum枚举所有错误码，附带默认消息（可选） - 或用普通类 + 类变量，保持简单（适合小项目）
- 异常构造时传入枚举成员，而非原始字符串，增强类型提示和校验
from enum import Enum
class ErrorCode(Enum):
USER_NOT_FOUND = "USER_NOT_FOUND"
INSUFFICIENT_BALANCE = "INSUFFICIENT_BALANCE"
raise BizError(ErrorCode.USER_NOT_FOUND.value, "用户未登录或已注销")
真正难的是错误码的生命周期管理：谁定义、谁审核、是否向客户端暴露、是否兼容旧版本。这些不在代码层面，但一旦疏忽，前端就只能靠 message 字符串做判断——那自定义异常就白做了。
