应捕获具体异常类型而非裸except，按功能分块try，善用else和finally：else执行成功逻辑，finally确保资源清理。
捕获具体异常比裸写 except: 安全得多
裸 except: 会吞掉所有异常，包括 KeyboardInterrupt（Ctrl+C）和 SystemExit，导致程序无法正常退出或调试困难。真正需要的是只拦截你预期中可能出问题的那类错误。
常见误用：try: do_something()except: print("出错了")
正确做法是明确写出异常类型：
- 文件操作失败 → 捕获
FileNotFoundError或PermissionError - 数字转换失败 → 捕获
ValueError - 字典键不存在 → 捕获
KeyError，而不是直接用.get()就完事（有些逻辑必须区分“没值”和“根本没这个键”） - 网络请求超时 → 捕获
requests.exceptions.Timeout（需先导入requests）
except 后加 as e 才能看清错在哪
只写 except ValueError: 而不绑定异常对象，等于放弃关键诊断信息。错误类型只是大类，真正定位问题靠的是 e.args 或 str(e) 里的具体提示。
示例：
try:
int("abc")
except ValueError as e:
print(f"转整数失败：{e}") # 输出：转整数失败：invalid literal for int() with base 10: 'abc'
注意：
- e 是异常实例，不是字符串，直接 print(e) 就行，不用 e.message（Python 3 已移除）
- 如果要记录日志，建议用 repr(e)，它能显示异常类型+消息+有时带地址，比 str(e) 更利于排查
别在 try 块里塞太多无关代码
把整个函数体包进一个 try，等于把“读配置”“连数据库”“发邮件”全混在一起处理，一旦出错根本分不清是哪步挂了，也难以针对性恢复。
应该按责任切分：
- 打开文件单独 try → 失败就换默认路径或报错退出
- 解析 JSON 单独 try → 失败就跳过该条数据，继续处理下一条
- 调用外部 API 单独 try → 配合重试机制，而非一错就崩
这样既方便加日志打点，也避免一个环节失败导致后续本可执行的逻辑也被跳过。
finally 和 else 不是装饰，是有明确分工的
finally 的唯一作用是「无论如何都要执行」，典型场景是资源清理：
- 文件 .close()（不过更推荐用 with）
- 数据库连接 .close() 或 .rollback()
- 临时目录 shutil.rmtree()
else 容易被忽略：它只在 try 块**没抛异常**时才运行，比把成功逻辑写在 try 末尾更语义清晰，也能避免把本不该被拦截的异常也裹进去。
比如：
try:
data = json.load(f)
except json.JSONDecodeError as e:
log.error(f"JSON格式错误：{e}")
data = {}
else:
process(data) # 只有解析成功才处理，process() 抛的异常不会被上面的 except 拦住
多层嵌套或复杂流程里，else 能让控制流更干净——它不是语法糖，是帮你把“成功路径”从“异常处理路径”里真正剥离开的关键工具。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
