历史：PEP 343 在 Python 2.5 中引入了 with 语句，标准化了之前需要冗长手动 try-finally 块的资源管理模式。该协议要求对象实现 __enter__ 和 __exit__ 方法，关键的创新在于 __exit__ 能够通过其返回值检查并选择性地抑制异常。此设计使得基础设施能够处理预期失败，而不会将其传播到业务逻辑中。
问题：当异常发生在 with 块内时，Python 会调用 __exit__(exc_type, exc_val, exc_tb)，其中包含活动异常的详细信息。如果此方法返回一个真值（在布尔上下文中被评估为 True），Python 认为异常已经处理并完全抑制传播。如果它返回 False、None 或任何假值，异常在 __exit__ 完成后正常传播，无论清理是否成功。
解决方案：实现 __exit__ 只在异常应该被故意吞掉时返回 True，例如预期的验证错误或瞬态网络故障。当清理完成但错误应该传播时，显式返回 False，或通过终止方法而隐性返回 None。该方法接收三个描述活动异常的参数，或者在正常退出时为 (None, None, None)。
class SuppressKeyError: def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): if exc_type is KeyError: print(f"吞掉：{exc_val}") return True # 抑制 return False # 传播其他异常 # 用法 with SuppressKeyError(): raise KeyError("被忽略") # 沉默 with SuppressKeyError(): raise ValueError("传播") # 抛出
场景：一个开发团队构建了一个分布式任务处理器，工作节点在执行关键部分之前通过 Redis 获取独占锁。当网络延迟导致 LockTimeout 异常时，系统应该透明地重试，而不是崩溃工作进程。然而，像 MemoryError 或编程错误这样的致命错误必须立即传播，以触发警报并防止无限重试循环。
问题：初始实现将 try-except 块分散在业务逻辑中，造成维护噩梦并模糊了实际领域代码。挑战是集中这种选择性抑制机制，同时不违反基础设施问题不污染领域代码的原则。
解决方案1：在调用点的每个任务执行中用显式嵌套的 try-except 块进行包装。优点：控制流对业务逻辑的读者立即可见，使新团队成员调试变得简单。缺点：此方法违反了 DRY，因在各处重复重试逻辑，紧密耦合业务代码与基础设施细节，并使单元测试变得困难，因为测试必须在每个调用点模拟锁失败，而不是模拟一个单独的上下文管理器。
解决方案2：创建一个 DumbSuppressor 上下文管理器，__exit__ 不加条件地返回 True。优点：实现仅需两行代码，完全消除了业务逻辑中的异常处理样板。缺点：这危险地吞掉所有异常，包括关键系统错误和编程错误，导致无声失败和无法调试的未定义应用状态。
解决方案3：实现 SmartRetryContext，检查 exc_type 是否在可配置的瞬态异常白名单中。优点：这声明性地集中重试逻辑，允许精确控制哪些错误触发重试与即时传播，并维持业务逻辑与基础设施关注点之间的干净分离。缺点：白名单需要小心维护，以避免意外抑制指示真实错误而不是瞬态基础设施问题的意外异常。
选择的方法：团队选择了解决方案3，因为它在安全性与功能性之间取得平衡。__exit__ 方法检查 issubclass(exc_type, RetriableException)，仅对网络超时等瞬态故障返回 True，同时允许编程错误立即显示以进行调试。
结果：系统通过自动重试优雅地处理 Redis 延迟尖峰，同时在出现错误时适当地崩溃。监控仪表板显示，从瞬态故障中减少了 40% 的警报噪音，开发人员可以编写任务逻辑而无需担心锁获取的细节。
问题： Python 的 __exit__ 方法返回 None 与返回 False 的行为有何区别，为什么两者都导致异常传播，尽管 None 是假值？
答案。许多候选人错误地认为返回 None 表示 "没有意见"，而 False 则积极请求传播。在 Python 中，两者在布尔上下文中都是假值，协议明确检查 if not exit_return_value: propagate_exception()。因此，None 和 False 的行为相同——在两种情况下，异常都会传播。这一区别仅对代码可读性重要；False 表示故意传播，而 None 表示意外遗漏。
问题： 如果 Python 的 __exit__ 方法通过返回 True 故意抑制异常，但在其清理逻辑中引发了新异常，什么决定哪个异常传播到外部作用域？
答案。__exit__ 中引发的新异常完全替代原始异常。Python 首先评估 __exit__ 的返回值；如果它是真值，则准备抑制原始异常。然而，如果 __exit__ 自身在返回之前引发，则该新异常传播，原始异常消失，除非通过 raise NewException from original 显式链接。这与 finally 块不同，在 finally 块中的异常替代但可以与活动异常链接。
问题： 在什么情况下 Python 保证即使在进入 __enter__ 之后也不会调用 __exit__，这与 finally 块的保证有何不同？
答案。如果 __enter__ 引发异常，Python 永远不会调用 __exit__，因为上下文从未成功建立。这与 try-finally 语义形成鲜明对比，在 try 语句立即引发时 finally 块仍会执行。这一区别对于资源管理至关重要：在失败之前部分在 __enter__ 中分配的资源必须在 __enter__ 本身内使用 try-finally 清理，因为 __exit__ 将不会运行以清理他们。