contextlib.suppress 更优雅，因为它明确表达“仅忽略指定异常”的语义，避免空 except: 意外吞掉 KeyboardInterrupt 等关键异常，且作为上下文管理器能确保资源正常清理。
为什么不用 try/except 来忽略异常反而更优雅？
因为 try/except 专为「处理异常」设计，而「忽略异常」本质是「不响应、不传播、不记录」——用 contextlib.suppress 明确表达这个意图，代码语义更干净，也避免了空 except: 带来的隐式风险。
常见误用：except Exception: pass 会吞掉 KeyboardInterrupt 和 SystemExit（它们继承自 BaseException 而非 Exception），但 suppress 只捕获你明确列出的类型，不会越界。
suppress 的基本用法和参数限制
contextlib.suppress 接收一个或多个异常类，仅在这些异常被抛出时静默终止，其他异常照常冒泡。它不接受异常实例、字符串或通配符。
- ✅ 正确：
suppress(ValueError, OSError) - ❌ 错误：
suppress("ValueError")、suppress(ValueError())、suppress(ZeroDivisionError, ...) - ⚠️ 注意：传入
BaseException仍不会拦截KeyboardInterrupt—— 这是 Python 解释器级保护，任何上下文管理器都无法绕过
示例：
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
立即学习“Python免费学习笔记（深入）”；
from contextlib import suppress
<h1>忽略文件不存在时的 FileNotFoundError，其他异常（如 PermissionError）仍抛出</h1><p>with suppress(FileNotFoundError):
os.remove('/tmp/stale.lock')</p><h1>多个类型同时忽略</h1><p>with suppress(KeyError, AttributeError):
value = config['host'].lower()
suppress 和空 except 在资源清理上的关键差异
很多人以为两者行为一致，但实际在 __exit__ 执行时机上存在微妙差别：如果 suppress 捕获到匹配异常，它会正常执行 with 块末尾的清理逻辑（比如文件关闭、锁释放）；而手写的空 except 若写在错误位置，可能意外跳过 finally 或上下文管理器自身的 __exit__。
- ✅
suppress是标准上下文管理器，保证__exit__被调用，资源释放不受影响 - ❌ 手动
try: ... except SomeError: pass若嵌套在另一个with内，容易因缩进或逻辑分支遗漏清理 - ? 场景举例：临时取消只读文件的只读位再删除，用
suppress可确保os.chmod后续操作不被中断，且os.remove失败时也不影响chmod回滚逻辑（如果封装得当）
suppress 不适合哪些场景？
它只做一件事：静默指定异常。一旦需求超出「忽略」范畴，就该换方案。
- 需要记录日志？→ 用
try/except+logging.warning() - 需要 fallback 行为（如缺配置时用默认值）？→ 用
try/except+else或赋值表达式 - 需要区分异常原因（如同样是
OSError，但 errno=13 是权限问题，errno=2 是路径不存在）？→suppress无法 inspect 异常对象，必须用完整except块 - 需要抑制异步异常（如
asyncio.CancelledError）？→suppress不支持 async with，得用try/except配合await
真正容易被忽略的是：suppress 不会帮你判断「该不该忽略」——比如忽略 ConnectionResetError 可能掩盖服务端崩溃，而忽略 FileNotFoundError 在清理临时文件时通常是安全的。这个决策始终要靠人来定。
