Python中try-except-else-finally严格按try→except（首个匹配）→else（无异常时）→finally（总执行）顺序执行；else与except互斥，finally总执行且可覆盖返回值。
try except else finally 的执行顺序怎么理解
这四个块不是随意排列的，Python 严格按 try → except（匹配到的第一个）→ else（仅当没异常时执行）→ finally（无论是否异常、是否 return 都执行）的顺序走。关键点是：else 和 finally 都不是可选的“补充说明”，而是有明确触发条件的独立分支。
常见误解：以为 else 是“异常处理失败后执行”，其实它和 except 是互斥的——只要进了某个 except，else 就完全跳过。
-
try块里发生异常 → 跳转到匹配的except→ 跳过else→ 执行finally -
try块里没异常 → 跳过所有except→ 执行else→ 执行finally -
try或except中有return→finally仍会执行（甚至可能覆盖返回值）
else 块到底该放什么代码
else 不是用来“兜底补救”的，而是专为“依赖 try 中成功执行结果、且本身不该抛异常”的逻辑设计的。典型场景是：打开文件成功后读取内容、网络请求成功后解析 JSON、数据库查询成功后处理结果。
错误做法：把可能出错的操作塞进 else，比如在 else 里再调用一个没做异常防护的函数——这会让异常漏过 except，直接崩掉。
立即学习“Python免费学习笔记（深入）”；
- ✅ 推荐：
try只包真正可能出错的初始化/获取动作（如open()、requests.get()）；else放后续安全操作（如.read()、.json()） - ❌ 避免：
else里写json.loads(data)却不捕获JSONDecodeError，因为这个异常不会被前面的except捕获 - 性能影响：
else不增加开销，但能减少except的覆盖范围，让异常处理更精准
finally 里修改返回值会怎样
finally 的执行优先级极高，哪怕 try 或 except 中已有 return，Python 也会先暂存那个返回值，执行完 finally 再决定最终返回什么——如果 finally 里也有 return，就会直接覆盖前面的值。
def demo():
try:
return "from try"
except:
return "from except"
else:
return "from else"
finally:
return "from finally" # 实际返回这个
这种写法极易引发逻辑混乱，尤其在需要保证返回值语义一致的函数中。除非你明确需要拦截并统一返回（比如日志+兜底值），否则 finally 应只做清理工作（关闭文件、释放锁、断开连接）。
- ✅ 安全用法：
finally中调用file.close()、conn.close()、lock.release() - ⚠️ 危险信号：如果
finally里有return或raise，必须确认这是有意为之，且文档已注明 - 兼容性注意：该行为在 Python 2.7+ 和 3.x 中一致，无版本差异
多个 except 和具体异常类型怎么选
写 except Exception: 看似省事，实则掩盖问题。应该根据实际可能抛出的异常类型分层捕获，比如 FileNotFoundError 和 PermissionError 处理方式完全不同。
常见错误是把宽泛异常放在前面，导致更具体的异常被提前吞掉：
except Exception: # 这行会捕获所有，包括下面的 FileNotFoundError
pass
except FileNotFoundError: # 永远执行不到
pass
- ✅ 正确顺序：从具体到宽泛，如
except ValueError→except OSError→except Exception - ✅ 推荐写法：用元组捕获多个同类异常，如
except (ConnectionError, TimeoutError): - ⚠️ 注意：
except:（空 except）会捕获KeyboardInterrupt和SystemExit，导致 Ctrl+C 失效，应避免
最常被忽略的是：else 和 finally 不是语法糖，它们的存在是为了让“成功路径”和“必执行清理”在逻辑上彻底分离。一旦混用或跳过，异常流就容易失控。
