捕获特定异常比全局 except 更安全，因后者会吞掉 KeyboardInterrupt 和 SystemExit；应按实际错误类型捕获，如 FileNotFoundError、ConnectionError；多异常用元组但勿堆砌；不确定时用 except Exception:；捕获后须日志或 re-raise；finally 在 os._exit() 或 SIGKILL 时不执行；else 用于无异常才执行的逻辑，提升错误定位精度；嵌套 try 比长链 except 更清晰。
捕获特定异常比用 except: 全局兜底更安全
直接写 except: 会吞掉所有异常，包括 KeyboardInterrupt（Ctrl+C）和 SystemExit，导致程序无法正常中断或退出。这不是“保险”，是埋雷。
- 优先按实际可能出错的类型捕获，比如文件操作用
FileNotFoundError、PermissionError，网络请求用ConnectionError、TimeoutError - 多个异常可写成元组：
except (ValueError, TypeError):，但别堆太多，否则掩盖问题本质 - 不确定时，至少用
except Exception:，避开BaseException子类（如SystemExit） - 捕获后别空着：至少打日志，或用
raise重新抛出，否则错误静默消失
finally 不等于“一定会执行”，它绕不开 os._exit() 和致命信号
finally 块在绝大多数退出路径下都会运行——但有两个硬例外：调用 os._exit()（不触发清理），或进程被 SIGKILL（kill -9）强制终止。
- 日常用
sys.exit()没问题，它会走finally；但os._exit()是底层退出，跳过所有 Python 层级的清理逻辑 -
finally适合关文件、释放锁、清理临时资源，但别在里面做耗时或可能再抛异常的操作（比如又去写磁盘） - 如果
try或except中已有return，finally仍会执行——但它不能改变已确定的返回值，除非它自己也return
用 else 分离“没异常才执行”的逻辑，避免误捕正常流程异常
else 块只在 try 里没抛异常时运行，且在 finally 之前。它不是语法糖，是明确责任边界的工具。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 常见误写：把本该放
else的代码塞进try，结果下游异常也被捕获，掩盖真实问题 - 典型场景：打开文件成功后才解析内容，
open()放try，json.load()放else，这样JSONDecodeError就不会被当成“打不开文件”处理 -
else里抛的异常不会被前面的except捕获，需另加处理——这反而是好事，逼你正视不同阶段的错误类型
嵌套 try 比长链 except 更易定位问题源头
一个函数里堆七八个 except 分支，看着全，实则难维护：哪一行出的错？哪个变量还没初始化？谁改了上游逻辑导致这里多抛了个异常？
立即学习“Python免费学习笔记（深入）”；
- 按职责拆：网络请求单独一层
try，数据校验再一层，序列化再一层——每层只管自己那块的错误语义 - 外层
except别重复处理内层已处理过的异常，比如内层已捕获TimeoutError并重试，外层就不用再写一遍 - 嵌套深了容易漏
finally，建议单层try控制在 10 行以内，复杂流程抽成小函数
真正难的不是写 try-except，是判断哪段代码值得包裹、包裹到什么粒度、以及当 finally 里的清理本身失败时，你还得决定是忽略、记录，还是让整个流程彻底失败。
