直接raise Exception('xxx')不够用，因为无法区分不同业务错误类型，导致捕获时只能依赖脆弱的字符串匹配，而自定义异常可通过类型精准识别语义，如except UserNotFound与except InsufficientBalance互不干扰。
为什么直接 raise Exception('xxx') 不够用
业务逻辑出错时，如果全用 Exception 或 ValueError 这类内置异常，调用方无法区分「用户手机号格式不对」和「数据库连接超时」——两者都抛 ValueError，但处理方式完全不同。捕获时只能靠字符串匹配错误信息，脆弱且不可维护。
自定义异常的核心价值不是“看起来高级”，而是让 except 语句能精准识别业务语义。比如：except UserNotFound 和 except InsufficientBalance 是完全独立的分支，互不干扰。
定义子类时必须重写 __init__ 吗
不是必须，但几乎总是需要。Python 的异常基类 Exception 默认接受任意位置参数，并把它们存进 args 元组，但不会自动转成可读的 str() 输出。如果你只写 class OrderExpired(Exception): pass，那么 raise OrderExpired("2024-01-01") 打印出来是 OrderExpired('2024-01-01')，缺少上下文。
更实用的做法是显式构造消息：
立即学习“Python免费学习笔记（深入）”；
class OrderExpired(Exception):
def __init__(self, order_id: str, expired_at: str):
self.order_id = order_id
self.expired_at = expired_at
super().__init__(f"Order {order_id} expired at {expired_at}")
这样既保留结构化字段（便于日志或监控提取），又保证 str(e) 可读。
要不要继承特定内置异常（如 ValueError）
要，但只在语义真正匹配时。比如参数校验失败，用 class InvalidPhoneFormat(ValueError) 是合理的，因为上层代码可能已捕获 ValueError 做通用参数错误兜底；但如果这是支付失败特有的异常，就不该继承 ValueError，而应直接继承 Exception。
常见误用：
- 为图省事全继承
RuntimeError—— 它表示“运行时意外状态”，和业务规则无关 - 层层嵌套继承，如
BaseBizError → AuthError → TokenExpiredError—— 增加理解成本，且多数场景不需要三层抽象 - 把 HTTP 状态码塞进异常名，如
HTTP403ForbiddenError—— 异常应表达“什么错了”，而不是“怎么响应”，状态码应在 handler 层映射
如何避免异常被静默吞掉
自定义异常再规范，如果上游用 except Exception: 一把抓，就全白费了。关键是在框架或入口处做两件事：
- 明确声明哪些异常是「预期中的业务异常」，比如 FastAPI 中用
@app.exception_handler(BizError)单独处理 - 禁止在工具函数里写空
except:或只打一行print("ignored") - 日志记录时务必输出
type(e).__name__，而不是只记str(e)，否则查问题时分不清是UserLocked还是UserNotFound
最易被忽略的一点：自定义异常类本身要放在稳定路径下（如 exceptions.py），避免循环导入——比如在 models.py 里定义异常，又被 services.py 导入，而 services.py 又被 models.py 依赖。
