python异常处理核心在于异常对象生命周期、栈帧传播及上下文管理器协同：raise构造实例并填充__traceback__，except捕获实例而非字符串，避免except exception:吞掉系统信号，with中__exit__返回true可阻断传播，自定义异常应继承exception而非baseexception。
Python 的异常处理不是“包一层 try-except 就完事”，关键在理解异常对象的生命周期、栈帧传播机制和上下文管理器的协同逻辑。
异常对象从 raise 到 except 是怎么“跑”过去的
当你执行 raise ValueError("bad input")，Python 实际做了三件事：构造 ValueError 实例、填充 __traceback__ 属性（指向当前栈帧）、暂停当前帧并向上查找能匹配的 except 块。这个过程不依赖全局变量或隐式状态，完全靠解释器维护的调用栈驱动。
-
raise后的代码不会执行，但finally一定会运行（哪怕在except中又raise） - 异常未被任何
except捕获时，会一直冒泡到模块顶层，最终触发sys.excepthook -
except ValueError as e:中的e是异常实例本身，不是字符串；str(e)才是消息文本
为什么 except Exception: 很危险，而 except BaseException: 更危险
Exception 是绝大多数内置异常的父类，但不包括 SystemExit、KeyboardInterrupt、GeneratorExit 等系统级退出信号。用 except Exception: 会意外吞掉本该终止程序的中断请求；而 except BaseException: 连 SystemExit(0) 都能捕获，导致 exit() 失效。
- 生产环境应避免裸写
except:或except Exception: - 真正需要兜底时，显式列出预期异常类型，例如：
except (OSError, ValueError): - 若必须日志记录后重新抛出，用
raise（不带参数）保持原 traceback，而非raise e（会丢失原始位置）
with 语句和异常传播的关系容易被低估
with 背后的上下文管理器（__enter__/__exit__）与异常处理深度耦合。__exit__ 方法接收三个参数：exc_type、exc_value、exc_traceback。它返回 True 表示“已处理异常，不要继续传播”，返回 None 或 False 表示“让异常继续往上走”。
立即学习“Python免费学习笔记（深入）”；
class SillyContext:
def __enter__(self):
return self
def __exit__(self, exc_type, exc_value, tb):
if exc_type is ValueError:
print("silently swallowed ValueError")
return True # 阻断传播
return False # 其他异常照常冒泡
<p>with SillyContext():
raise ValueError("gone") # 不报错，也不打印 traceback
with SillyContext():
raise TypeError("still here") # 正常抛出</p>自定义异常要继承 Exception，而不是 BaseException
除非你明确想制造一个连 except Exception: 都无法捕获的“系统级异常”，否则所有业务异常都应直接或间接继承 Exception。否则会导致上游调用方的常规异常处理逻辑失效，且不符合 PEP 20 的“显式优于隐式”原则。
- 推荐写法：
class ConfigLoadError(Exception): pass - 避免：
class ConfigLoadError(BaseException): pass - 可加字段增强调试能力：
def __init__(self, path, cause): self.path = path; self.cause = cause; super().__init__(f"Failed to load {path}: {cause}")
异常传播路径、<strong>exit</strong> 返回值含义、自定义异常的继承链——这三点一旦混淆，轻则掩盖真实错误，重则让程序卡死在不可见的静默失败中。
