自定义异常应继承Exception而非BaseException；类名须以Error结尾；__init__中必须调用super().__init__(message)；仅在业务语义不匹配内置异常时才自定义。
自定义异常该继承哪个基类
Python 中所有异常都应继承 Exception，而不是 BaseException（后者是系统退出、键盘中断等底层异常的父类）。继承 BaseException 会导致 except Exception: 捕获不到你的异常，还可能意外拦截 SystemExit 或 KeyboardInterrupt，破坏程序可控性。
实操建议：
- 业务逻辑异常一律继承
Exception - 若需分类管理（如 API 错误、数据校验错误），可设中间抽象类，例如
class ValidationError(Exception): pass - 避免直接继承
RuntimeError或ValueError除非语义完全匹配——否则会误导调用方对错误性质的判断
异常名要不要带 Error 后缀
要。PEP 8 明确建议异常类名以 Error 结尾（如 ConfigNotFoundError），这是 Python 社区通用约定。不加后缀（如 ConfigNotFound）会让使用者难以一眼识别其用途，也容易和普通类、数据类混淆。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- IDE 在
raise或except处缺少语法提示 - 团队代码 review 时反复质疑“这个类到底是干啥的？”
- 日志或监控系统按命名规则自动归类异常失败
__init__ 里要不要调用 super().__init__
要，且必须传入用户可读的错误消息。Python 异常的字符串表示（str(exc)）、日志输出、调试器显示都依赖 args 元组，而 super().__init__(message) 正是填充它的标准方式。
实操建议：
- 不要只写
pass或空__init__；否则str(e)返回空字符串，日志里只剩类名，无法定位问题 - 避免在
__init__中做耗时操作（如网络请求、文件读取）——异常实例化应轻量 - 若需附加结构化信息（如错误码、原始数据），用额外属性存储，例如
self.error_code = 4001，而非塞进 message
什么时候该抛出自定义异常，而不是用内置异常
当内置异常无法准确表达业务语义，或上层需要差异化处理时。比如用户权限不足，抛 PermissionError 看似合理，但它实际对应操作系统级权限，和业务角色权限不是同一维度；此时 InsufficientRoleError 更清晰，也方便 API 层统一转为 403 响应。
使用场景判断要点：
- 是否有多处相同语义错误，且需被同一
except块捕获？→ 适合自定义 - 是否需要携带业务专属字段（如订单 ID、租户 code）？→ 自定义更易扩展
- 是否希望在 Sentry 或 ELK 中按类型聚合统计？→ 命名明确的自定义异常更可靠
- 反之，参数类型错用就用
TypeError，键不存在就用KeyError，别为了“统一”强行包装
最易被忽略的一点：自定义异常类本身要能被序列化。如果走 RPC 或存入日志系统（如 JSON 格式），确保它不含不可序列化的属性（如 open 的 file 对象、lambda 函数），否则在跨进程/网络场景下会静默失败或报 TypeError: Object of type XXX is not JSON serializable。
