Python 中用 try/except 替代条件判断符合 EAFP 哲学，更 Pythonic 且线程安全，但仅适用于真正意外的异常；高频抛出会显著降低性能，应避免将异常作为常规控制流。
用 try/except 替代条件判断常见吗？
Python 的异常机制设计上就支持“EAFP”（Easier to Ask for Forgiveness than Permission），即先尝试操作，失败再捕获。这和 C 风格的“LBYL”（Look Before You Leap）不同。比如检查字典键是否存在：if 'key' in d: 是 LBYL；try: value = d['key'] 是 EAFP。两者在语义上等价，但 EAFP 在多数场景下更 Pythonic，也更线程安全（避免竞态条件）。
- 多数内置操作（如
dict.getitem、list.getitem）抛出异常成本很低，CPython 中已高度优化 - 但前提是异常是“真正意外”的——如果
KeyError每秒发生数千次，说明逻辑本该用dict.get()或预检 - 常见反模式：
try: x = int(s) except ValueError: x = 0用于所有字符串转整数，却不考虑s.strip()或空字符串等可预判情况
raise 和 return 混用控制流会怎样？
有人用自定义异常（如 StopIteration、GeneratorExit）跳出多层嵌套，甚至替代 return。这在极少数场景下可行（比如解析器早期退出），但绝大多数时候会让调用方困惑：
- 异常本意是“中断正常流程”，不是“返回值”
- 调用者没理由去
catch一个本不该发生的ParseDone异常 - 调试时堆栈里全是无关帧，掩盖真正问题
-
工具链（如类型检查器
mypy、IDE 自动补全）无法推断这种“伪返回”的行为
正确做法：用 return 显式返回，或封装为生成器用 yield + break。
哪些异常真适合当控制流用？
标准库中已有明确约定的例外可以接受：
立即学习“Python免费学习笔记（深入）”；
