suppress比try/except更轻量，因其不构建traceback、不创建帧对象，仅静默丢弃指定异常；适用于明确可忽略的场景（如FileNotFoundError），不处理未声明异常，且仅作用于with块内直接抛出的异常。
suppress 为什么比 try/except 更轻量？
因为 contextlib.suppress 不捕获异常后做任何处理，只是让指定异常“静默消失”，不打断执行流，也不需要写 pass 或空 except 块。它适合那些你明确知道可能抛出、但完全不关心结果的场景，比如清理临时文件、关闭可能已关闭的句柄。
常见错误是把它当通用异常处理器用——比如 suppress ValueError 而实际抛出的是 TypeError，结果异常照常冒泡，还误以为被拦截了。
- 只 suppress 明确知道会抛、且业务上可忽略的异常类型（如
FileNotFoundError、OSError） - 不能 suppress 基类异常（如
Exception）来兜底——这违背设计初衷，也掩盖真实问题 - 内部不记录、不重抛、不触发
__exit__的其他逻辑，纯“丢弃”行为
suppress 多个异常类型怎么写？
直接把多个异常类作为参数传入，用逗号分隔，顺序无关。它内部用 isinstance(exc, exception_types) 判断，所以子类异常也会被匹配。
例如想同时忽略文件不存在和权限拒绝，可以这样写：
立即学习“Python免费学习笔记（深入）”；
from contextlib import suppress
with suppress(FileNotFoundError, PermissionError):
os.remove('/tmp/stale.lock')
- 传入
OSError可以覆盖其所有子类（包括FileNotFoundError），但不如显式列出更清晰 - 不能传字符串或元组类型（如
('FileNotFoundError',)），会报TypeError: issubclass() arg 2 must be a class - 如果某次执行中抛出未列出的异常（比如
MemoryError），仍会向上冒泡
suppress 和 try/except pass 的性能差异大吗？
在绝大多数场景下，差异可忽略；但 suppress 确实略快一点，因为它跳过了异常对象的完整 traceback 构建和 except 块的帧对象创建。不过真正影响性能的是异常是否发生——频繁抛异常本身才是瓶颈。
- 没异常时，
suppress和空try几乎一样快 - 有异常时，
suppress比try/except: pass省掉一两个函数调用开销，但差别在纳秒级 - 别为了这点性能改写逻辑；优先选语义更准确的那个：该忽略就用
suppress，该处理或日志就用try/except
suppress 容易被忽略的边界情况
它只作用于 with 块内**直接抛出**的异常。如果异常来自线程、信号、子进程或异步回调，suppress 完全无效。
- 不会抑制
sys.exit()或os._exit()——它们不是异常，而是流程控制 - 嵌套
with suppress(...):时，外层 suppress 不会拦截内层未被其声明的异常 - 在生成器或协程里使用要小心：如果异常在
yield后抛出，且未被生成器内部处理，suppress依然生效；但如果异常来自send()或throw()调用，则取决于谁在调用上下文
最常踩的坑是：以为 suppress 能“全局静默”某个函数的所有异常，结果发现它只管当前 with 块那一行——多写一行代码，就得再包一层。
