应使用 contextlib.suppress 精准静默已知可忽略异常（如 FileNotFoundError），避免用 suppress(Exception) 掩盖逻辑错误；@contextmanager 必须将资源初始化与清理统一置于 try/finally 中，防止 yield 前异常导致资源泄漏。
直接用 contextlib.suppress 忽略已知可忽略的异常，用 @contextmanager 写自定义资源管理器时必须把初始化和清理都包进 try/finally，否则 yield 前出错会导致资源泄漏。
suppress 只该用于明确预期且安全忽略的异常
它不是兜底工具，而是精准静默——比如删文件前不检查是否存在，就直接用 suppress(FileNotFoundError)。
- 常见错误：拿
suppress(Exception)想“防崩”，结果掩盖了真正该暴露的逻辑错误 - 正确场景：清理临时目录、关闭可能已断开的 socket、卸载未成功挂载的模块
- 注意：
suppress不捕获KeyboardInterrupt和SystemExit，这两类仍会中断流程 - 可叠加多个类型：
with suppress(FileNotFoundError, OSError): os.rmdir("tmp")
@contextmanager 中 yield 前抛异常 = 资源泄漏
这是最常被踩的坑：函数刚打开文件或获取锁，还没 yield 就因校验失败抛了 ValueError，后面的 close() 或 release() 根本不会执行。
- 必须把所有资源操作（open、acquire、connect）和清理（close、release、disconnect）塞进同一个
try/finally块 -
yield只能出现一次，且只负责交出资源对象，不做任何前置判断 - 示例中若
f = open(path, "w")失败，finally里的f.close()会因f未定义而报NameError，所以得先初始化为None并判空 - 网络请求、数据库连接等耗时操作别放 yield 前；真要校验，提前在 with 外做
closing 不能传 None，且不吞异常
closing 的作用很窄：给只有 .close() 方法的对象补上下文协议，但它不处理空值，也不拦截异常。
立即学习“Python免费学习笔记（深入）”；
- 错误写法：
with closing(get_conn()) as conn:—— 若get_conn()返回None，closing(None).close()会触发AttributeError - 正确做法：调用前确保非空，或自己包一层
if obj is not None: obj.close() -
closing的__exit__总是返回False，所以它不抑制任何异常，只是确保close()执行 - 适用对象：老式库返回的
urllib.request.urlopen、某些数据库驱动的连接实例、自定义类里只写了close但没实现协议的
多资源协同必须严格控制顺序和容错边界
一个上下文管理器里同时管锁 + 文件 + 连接时，释放顺序必须逆序，且任一环节失败都不能跳过其他资源的清理。
- 锁必须在文件打开前 acquire，否则 open 失败会导致锁永远不 release
- 游标依赖连接？那
__exit__里得先关游标再关连接，反过来会报ProgrammingError - 不推荐在一个
@contextmanager里混管长生命周期连接和短生命周期临时文件——应拆成嵌套with lock_ctx(), file_ctx(): - 动态数量资源（如批量打开 N 个文件）优先用
contextlib.ExitStack，它支持enter_context累加并自动逆序退出
真正容易被忽略的是：@contextmanager 函数内部的异常堆栈比类实现更深一层，调试时看到的 traceback 里夹着生成器帧；而 closing 和 suppress 这类轻量工具，一旦用错类型或传错对象，错误往往延迟到运行时才暴露，静态检查几乎无法捕获。
