Python异常处理核心是理解“谁抛出、谁捕获、谁处理、谁传递”的协作逻辑，本质是控制流主动切换；需依责任边界选择宽泛或精确捕获，避免空捕获、丢失traceback及except顺序错误。
Python异常处理的核心不是记住所有错误类型，而是理解“谁抛出、谁捕获、谁处理、谁传递”这四个动作的协作逻辑。真正卡住初学者的，往往不是语法写错，而是没想清楚：这个异常该在函数里吞掉？还是往上交？或者必须立刻终止程序？本讲直击本质，用真实场景讲清原理和取舍。
异常的本质：不是失败，而是控制流的主动切换
Python中raise不是“报错”，而是发出一个信号——“当前流程无法继续，请跳转到能处理它的位置”。就像按了电梯的“紧急停靠键”，系统会立刻中断当前执行，沿调用栈向上查找except块。
- 没有except匹配？继续往上找，直到进入sys.excepthook（最终打印 traceback）
- 遇到finally？无论是否捕获，都执行——这是清理资源的唯一可靠时机
- 用return提前退出except？不会触发finally之后的代码，但finally本身仍会执行
捕获策略：什么时候该宽泛，什么时候要精确？
盲目用except Exception:看似保险，实则掩盖问题；死守except ValueError:又容易漏掉真实原因。关键看责任边界：
- 底层工具函数（如解析JSON）：只捕获明确预期的异常（json.JSONDecodeError），让调用方决定如何应对
- 业务入口（如Web接口视图）：用except Exception:兜底，记录日志并返回友好提示，防止崩溃
- 资源操作（如文件读写）：优先用with自动管理，异常时在finally或上下文管理器中确保关闭
实战案例：一个HTTP请求函数的异常演进
从裸写到健壮，看异常处理如何层层加码：
- 版本1（裸奔）：requests.get(url) —— 网络断、超时、404、500全变成未处理异常，程序直接挂
- 版本2（基础防御）：包一层try/except requests.RequestException，区分网络层错误，但业务状态码（如401）仍需手动检查
- 版本3（语义化处理）：自定义ApiError异常，在except中根据response.status_code抛出不同子类（UnauthorizedError、NotFoundError），上层可精准响应
- 版本4（可观测性）：在except中打结构化日志，记录URL、耗时、headers片段，不暴露敏感参数
容易忽略的关键细节
这些点
不写错语法，但一错就埋雷：
- except:（空捕获）会吞掉KeyboardInterrupt和SystemExit，导致Ctrl+C失效
- except Exception as e:后忘记raise或raise e——丢失原始traceback，调试时找不到源头
- 在except里修改了e的属性再抛出？原始异常对象已不可逆改变，建议用raise NewError(...) from e链式保留上下文
- 多个except块顺序错误：子类异常写在父类后面，永远触发不到（如ValueError在Exception之后）
