else 子句是“无异常时才执行”的明确信号，非兜底逻辑；它只在try块静默结束时运行，不受except影响，错误放入会污染异常栈、增加调试难度。
else 子句在 try 语句中不是“兜底逻辑”，而是“无异常时才执行”的明确信号——用错地方反而会让错误更难定位。
为什么 else 不是 except 的简化写法
很多人误以为 else 是为了少写一个 except，其实它解决的是“执行时机”问题：只有 try 块里没抛出任何异常（包括隐式异常，比如 1/0、dict['missing']），else 才运行。一旦 try 中调用了可能触发异常但你又不想捕获的函数（比如日志记录、资源释放前的校验），放进去就会污染异常栈。
常见错误现象：else 里调用 os.remove() 报 FileNotFoundError，但 traceback 显示异常来自 else 而非原始业务逻辑，排查时容易绕弯。
- 使用场景：适合放“依赖 try 成功执行后才安全进行”的操作，比如数据库 commit、文件 close、异步任务提交
- 不能放：任何可能抛异常且你没准备处理的操作（哪怕概率低）
- 性能影响：几乎为零；但滥用会增加调试成本
else 和把代码挪到 try 末尾有啥区别
表面看只是换了个缩进位置，但语义和行为完全不同。放在 try 末尾的代码，只要前面任意一行抛异常，它就不会执行；而 else 只关心是否发生异常，不关心异常类型或是否被 except 捕获。
立即学习“Python免费学习笔记（深入）”；
示例对比：
try:
data = json.loads(payload)
process(data) # ← 如果这里抛 ValueError，不会进 else
except json.JSONDecodeError:
log_error("bad json")
else:
notify_success() # ← 仅当 json.loads 成功且 process 没抛异常才触发如果把 notify_success() 放进 try 最后，它会在 process() 抛出未被捕获异常时跳过；但放进 else 后，只要 process() 抛了任何异常（包括你没列在 except 里的），else 就不执行——这是设计意图，不是 bug。
- 关键差异：else 不受 except 分支影响，只响应 try 块整体是否静默结束
- 容易踩的坑：在 else 里调用可能失败的第三方库方法，却没配对应的 except
- 兼容性：Python 2.6+ 全支持，无版本顾虑
什么时候该坚持不用 else
当你的“成功后续操作”本身需要容错能力时，else 就不合适。比如发通知邮件，网络临时不可达应该重试而非让整个流程中断；这种逻辑必须显式包裹在自己的 try/except 里，而不是指望外层 else。
- 典型场景：发送 HTTP 请求、写监控指标、触发 webhook
- 正确做法：在 else 里再套一层 try，或直接把这类操作移出 try/else 结构
- 反模式示例：
else: requests.post("https://hook", json=report)—— 一旦超时，整个 try/except 流程就因未捕获的 ConnectionError 中断
真正容易被忽略的点是：else 不是语法糖，它是控制流契约——它承诺“此处代码绝不会看到 try 中抛出的异常”，所以一旦你在这里加了可能破约的操作，就得自己负责兜住。否则，异常来源会变得模糊，尤其是嵌套多层 try 时。
