业务异常是可预期的业务规则错误，应主动定义并抛出；系统异常是不可预测的运行环境问题，需防御性捕获。二者须严格区分，避免混用误导定位或掩盖本质。
业务异常和系统异常在 Python 中的核心区别在于：前者是程序逻辑中可预期的、与业务规则相关的错误，应该由开发者主动抛出并处理；后者是运行环境或底层资源导致的意外问题，通常不可预测，需要防御性编程来捕获和兜底。
业务异常：为规则服务，应主动定义
业务异常反映的是“不该发生但能说清楚原因”的情况，比如用户余额不足、订单已取消、手机号格式不合法等。它们不是代码缺陷，而是业务流程中的合理分支。
- 建议继承 Exception（而非 BaseException），避免干扰系统级退出
- 命名体现业务含义，如 InsufficientBalanceError、InvalidOrderStatusError
- 在关键业务判断处显式 raise，例如：
if order.status == 'cancelled':
raise InvalidOrderStatusError("订单已取消，无法发货")
系统异常：由运行环境触发，需谨慎捕获
系统异常来自解释器、操作系统或外部依赖，比如网络超时（TimeoutError）、文件不存在（FileNotFoundError）、内存耗尽（MemoryError）。它们往往不可控，也不该被业务逻辑直接依赖。
- 避免裸捕获 except: 或 except Exception:，优先捕获具体异常类型
- 对 I/O 类异常（如 requests 请求失败）做重试或降级，而不是转成业务异常掩盖本质
- 记录日志时保留原始异常链，用 raise ... from e 保持上下文
两者混用的典型误区
把数据库连接失败（系统异常）包装成“用户登录失败”（业务异常），会误导问题定位；反过来，把“密码错误”当作 ValueError 抛出而不定义专属类型，又会让上层难以区分处理逻辑。
- 不要用系统异常类型表达业务语义（如用 PermissionError 表示权限不足——它本意是 OS 层拒绝访问文件）
- 不要在 except 块里吞掉系统异常后静默返回默认值，除非你明确知道后果且有监控兜底
- API 接口层可将二者统一转换为响应结构，但内部仍需严格区分来源和处理方式
