except Exception 会吞掉本该暴露的 Bug，因为它捕获 AttributeError、TypeError、ImportError 等代码缺陷类异常，掩盖真实问题；真正应捕获的是具体异常如 ConnectionError 或 Timeout，并在顶层入口等极少数场景才考虑宽泛捕获且需完整记录 traceback。

为什么 except Exception 会吞掉本该暴露的 Bug

它不是“太宽泛”，而是直接屏蔽了开发阶段最该被发现的错误类型。比如 NameError（变量名写错）、SyntaxError（语法错误）虽不继承自 Exception，但 except Exception 仍会捕获 AttributeError、TypeError、ImportError 这些明显属于代码缺陷的异常——它们和 FileNotFoundError 的性质完全不同，不该用同一套逻辑兜底。

except: 和 except Exception: 的实际差异在哪

两者都危险，但危险方式不同：

• except: 会捕获 SystemExit、KeyboardInterrupt、GeneratorExit，导致 Ctrl+C 失效、服务无法正常退出
• except Exception: 虽避开上述三类，但仍捕获所有业务逻辑级异常，把 KeyError 当成可重试错误、把 UnboundLocalError 当成临时故障，掩盖真实问题
• 真正该捕获的，往往只是某个明确场景下的具体异常，比如 requests.get() 可能抛 ConnectionError 或 Timeout，而不是整个 Exception 族

什么情况下才该考虑宽泛捕获

极少数场景下，宽泛捕获是必要且可控的：

Secure Python Code Sandbox

安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。

下载

• 顶层入口（如 CLI 主函数、Web 框架的全局异常处理器），用于兜底并友好报错，但必须完整记录 traceback
• 异步任务队列中单个任务的隔离执行，防止一个失败任务拖垮整个 worker，但需确保日志包含原始异常类型和堆栈
• 与外部系统交互时，已明确该接口文档中只定义了有限几种失败模式，且你已为每种写了对应处理逻辑——此时应显式列出它们，而非用 Exception

替代方案：用更小、更具体的异常范围

与其退一步写 except Exception，不如前进一步拆解：

立即学习“Python免费学习笔记（深入）”；

• 查文档或源码，确认可能抛出的具体异常类型，例如 json.loads() 可能抛 JSONDecodeError（3.5+ 是 ValueError 子类，但显式捕获更清晰）
• 用元组一次捕获多个相关异常：except (ConnectionError, Timeout)
• 对不确定的异常，宁可让程序崩溃，也别静默吞掉；崩溃日志比“看似运行正常实则结果错误”更容易定位问题
• 若真需要兜底，至少加一行 logging.exception("unhandled exception in ...")，而不是 pass 或模糊打印

真正难的不是写 except，而是判断哪一层该捕获、哪一层该让异常冒泡——这个决策点一旦错位，后续所有日志、监控、告警都会失真。