Python异常体系按语义层级组织为BaseException→Exception→具体异常三层结构，自定义异常应继承Exception并构建业务语义明确的继承链，避免继承BaseException、命名模糊或过度细分。
Python的异常体系不是随意堆砌的，而是按语义层级精心组织的。理解这种分层逻辑，能帮你写出更清晰的错误处理代码，也能设计出符合Python惯例的自定义异常。
内置异常的三层结构
Python内置异常构成一棵树，根节点是BaseException，日常开发中几乎不会直接捕获它。真正实用的是它的子类Exception——绝大多数业务异常都继承自它。
Exception之下又自然分成几大类：
- 系统级错误：如OSError（文件、网络、权限等）、RuntimeError（运行时状态异常）
- 程序逻辑错误：如ValueError（参数值不对）、TypeError（类型不匹配）、KeyError（字典键不存在）
- 控制流异常：如StopIteration、GeneratorExit，通常由解释器内部使用，一般不手动抛出
自定义异常的设计原则
为项目添加异常时，应紧贴业务语义，并复用已有层级。不要平铺创建一堆并列异常类，而要构建有深度的继承链。
立即学习“Python免费学习笔记（深入）”；
例如做支付模块：
- 定义基类PaymentError(Exception)，所有支付相关异常的父类
- 再细分InsufficientBalanceError(PaymentError)、InvalidCardError(PaymentError)
- 必要时还可进一步细化，比如ExpiredCardError(InvalidCardError)
这样捕获时就能按需选择粒度：except PaymentError兜底，或except InsufficientBalanceError做特定补偿。
避免常见设计陷阱
新手常犯的错误包括：
- 让自定义异常继承BaseException或SystemExit等特殊异常——这会干扰程序正常退出流程
- 异常名含模糊动词（如HandleFailedError），不如明确表达“什么错了”，比如PaymentRefundFailedError
- 过度细分，为每个HTTP状态码都建一个异常类——应按语义聚类，比如ApiConnectionError和ApiAuthenticationError比Api401Error、Api503Error更易维护
异常文档与一致性维护
在包的__init__.py中集中导入常用异常，方便使用者统一导入；同时在文档中说明各异常的触发场景和恢复建议。
例如：
- UserNotFoundError：用户ID不存在，调用方应检查输入或提示用户重试
- ConcurrentUpdateError：版本冲突，建议重试或提示用户刷新页面
保持异常命名、分类和文档同步更新，团队协作时才能高效定位和响应问题。
