else子句仅在try块无异常时执行，用于分离正常逻辑与异常处理，避免误捕获或静默失败。
try-except-else 的作用不是“兜底”，而是明确分离正常路径和异常路径
很多人误以为 else 是可选的“补充逻辑”，其实它的核心价值在于：**只有当 try 块中完全没触发任何异常（包括没被 except 捕获的异常）时，else 才会执行**。它天然排除了因异常处理逻辑自身出错导致的误执行风险。
常见错误现象：else 里调用了可能抛异常的函数（比如 json.loads()），结果异常被跳过、程序静默失败；或者把本该放 try 里的操作挪到 else，导致异常无法被捕获。
-
else必须紧跟在except（或except块序列）之后，不能单独存在 -
else不接收异常参数，也不参与异常匹配 —— 它只响应“零异常”这个布尔状态 - 适合放在
else里的代码：纯计算、日志记录、资源释放（前提是不抛异常）、调用已知稳定的函数（如len()、str.format()）
什么时候必须用 else 而不是把代码塞进 try
典型场景是避免将“本不该被异常中断”的逻辑卷入异常捕获范围。例如读取配置后解析 JSON：
try:
data = read_config_file("config.json") # 可能 FileNotFoundError / PermissionError
# ❌ 错误：把 json.loads 放这里，若解析失败，会被上面的 except 捕获，掩盖真实问题
config = json.loads(data)
except FileNotFoundError:
config = DEFAULT_CONFIG
正确写法是把解析逻辑移入 else：
立即学习“Python免费学习笔记（深入）”；
try:
data = read_config_file("config.json")
except FileNotFoundError:
config = DEFAULT_CONFIG
else:
# ✅ 只有读取成功才解析，且解析异常不会被 FileNotFoundError 的 except 捕获
config = json.loads(data) # 若这里报 JSONDecodeError，会直接冒泡
- 如果
json.loads()出错，你希望它暴露为原始异常（而不是吞掉变成默认配置），就该用else - 如果还想处理
JSONDecodeError，就加对应except JSONDecodeError:，它必须写在else之前（即作为另一个except分支） -
try内应只放“可能出问题且你准备处理”的语句；其余依赖前序成功的操作，优先放else
else 和 finally 的行为差异容易混淆
else 和 finally 都在 try 后执行，但触发条件完全不同：
-
else：仅当try无异常且未执行return/break/continue时运行 -
finally：无论是否异常、是否return、是否sys.exit()，只要进入try块就一定会执行（极少数情况如进程被 kill 除外） - 若
try中有return 1，则else不执行，finally仍执行，且其内部return会覆盖前面的返回值
一个易踩坑的例子：
def load_and_validate():
try:
return int(input("Enter number: "))
except ValueError:
print("Invalid input")
return -1
else:
print("Parsed successfully") # ❌ 这行永远不会执行：try 中已有 return
此时 else 形同虚设 —— 因为 try 块内提前 return，控制流根本不会走到 else。
实际项目中 else 的典型用法
真实代码里 else 出现频率不高，但一旦用对，逻辑清晰度提升明显。常见模式：
- 数据库查询成功后更新缓存：
try执行cursor.execute()，else调用cache.set()（确保只在查询成功时缓存） - 文件打开成功后校验内容长度：
try用open()，else读取并检查len(f.read()) > 0，避免空文件被当作有效数据 - 网络请求成功后解析响应：
try调用requests.get()，else处理res.json()或res.text，让 HTTP 异常和解析异常分层捕获
关键点在于：所有放进 else 的代码，都必须满足两个条件 —— 它依赖 try 成功，且它自己不该引入新的、需要被同一层 except 捕获的异常。
