try-except本身不慢，但用错地方会拖慢程序：当异常常见可预期时应优先用if判断（如键存在性、字符串数字校验、文件存在性），而仅在低频不可预测场景（如网络请求、JSON解析）中使用try-except才真正高效。
为什么try-except本身不慢，但用错地方会拖慢程序
Python的try-except机制在没有异常发生时开销极小，几乎可忽略；真正拖慢程序的，是把本该用条件判断解决的问题，硬塞进try-except里反复触发——比如用KeyError代替dict.get()检查键是否存在，或用ValueError代替str.isdigit()做字符串预判。
哪些场景该用if而不是try-except
当“异常情况”其实很常见、可预期时，try-except反而更重。典型例子：
- 检查字典键：
if key in my_dict:比try: my_dict[key] except KeyError:快 3–5 倍（尤其键不存在概率 >10%） - 字符串转数字：
if s.isdigit(): int(s)比try: int(s) except ValueError:更稳更快（int()对负号、小数点等会抛异常，isdigit()不能覆盖全部，但可组合s.lstrip('-').isdigit()作轻量预检） - 文件存在性：
if os.path.exists(path): open(path)比try: open(path) except FileNotFoundError:更直接（且避免TOCTOU竞态问题）
try-except该用在哪，才真正高效
它适合处理**低频、不可预测、成本远高于预检**的失败场景，比如网络请求、磁盘IO、第三方库内部状态突变：
- HTTP请求：预检URL格式没用，真正失败在连接或响应阶段，
try: requests.get(url) except requests.RequestException:是合理选择 - JSON解析：用户输入不可控，
json.loads()抛JSONDecodeError的代价远低于手写状态机校验 - 并发资源竞争：如
threading.Lock.acquire(blocking=False)失败后，用except捕获并退避，比轮询lock.locked()更省CPU
性能验证和调试技巧
别靠直觉，用timeit或cProfile实测关键路径：
立即学习“Python免费学习笔记（深入）”；
# 对比键查找
python -m timeit -s "d = {1:2}" "1 in d"
python -m timeit -s "d = {1:2}" "try: d[1] except KeyError: pass"
注意：try-except块内避免放耗时操作（如循环、IO），否则异常开销会被放大；也别在热循环里嵌套多层try——把异常处理提到外层更清晰、更快。
最常被忽略的是：异常对象构造本身有成本（填充traceback、收集栈帧），哪怕你except Exception: pass，只要异常被抛出，这部分开销就已发生。
