排查 FastAPI 依赖链中的异常吞噬

FastAPI 的依赖注入能把鉴权、数据库连接和租户校验拆成独立组件，但只要其中一层把异常吞掉，后面看到的报错就可能偏离真正故障。原文提出两道防线：提交时用 AST 扫描危险写法，运行时用 ASGI 中间件记录逃出的异常。

思路值得借鉴，不过它给出的实现并没有撑起「消除静默失败」的结论。读这篇最有价值的地方，是弄清异常为什么会失去线索，以及静态检查和请求边界日志各自能管到哪里。

为什么数据库断连，最后却报成了空对象错误

FastAPI 通过 Depends 组织依赖，并按依赖关系解析后再调用路由。原文用鉴权、数据库会话、租户校验到业务端点的链条举例。这里的有向无环图（DAG），可以理解为：框架先根据组件之间的依赖关系，把路由需要的对象准备好。

风险发生在某个提供依赖的函数捕获异常后，继续返回一个看起来合法、实际不可用的结果。

下面这段代码展示了数据库故障如何被变成 None：

def get_db_session():
    try:
        # 模拟基础设施故障或连接失败
        raise ConnectionError("Database cluster unreachable")
    except Exception as e:
        # 反模式：吞掉异常，返回 None 或静默跳过
        pass 
    return None

要盯住的是 pass 后面的 return None：调用方拿不到数据库会话，也收不到失败信号。

下游的 Depends(verify_tenant) 如果继续执行 db.query(...) 或 await db.execute(...)，就可能抛出 AttributeError。原文给出的典型错误是：

AttributeError: 'NoneType' object has no attribute 'query'

此时，Sentry、Datadog 或全局异常处理器可能只记录到租户校验附近的空对象错误。真正应该排查的数据库连接故障，被后续错误遮住了。客户端收到的仍可能是普通的 500 Internal Server Error，但服务端失去了更有用的定位入口。

吞异常最直接的代价，是把失败发生的位置和最终报警的位置拆开了。

不过，原文把原始异常描述为从内存中完全丢失，表述过于绝对。这里能够确定的是：这段代码没有记录或向外传播原始异常，后续错误通常无法沿异常链找到它。是否还有其他地方保留记录，取决于实际系统。

AST 检查能拦住危险写法，但读不懂完整意图

作者提出用 Python 的抽象语法树（AST）扫描源码。它比搜索 except Exception 更进一步：程序能够识别异常处理块，再检查块里出现了什么语法结构。

原文的 ExceptionSwallowingVisitor 继承 ast.NodeVisitor，在 visit_Try 中识别三类宽泛捕获：

• 没写异常类型的 except:。
• 捕获 Exception 的处理块。
• 捕获 BaseException 的处理块。

随后，它用 ast.walk(handler) 查找 ast.Raise，并寻找方法名为 error、exception、critical、warning 的调用。

这里有个关键出入：文字说的是，没有重新抛出、也没有日志时才报告风险；实际代码却只用 if not has_raise 决定是否生成发现记录。has_logging 只是报告字段，不影响是否命中。

所以，照给出的代码执行，即使写了 logger.exception(...)，只要没有 raise，仍会被报告。这个规则究竟是要求「不能静默」，还是要求「宽泛捕获后必须抛出」，原文没有统一。

这种扫描也有边界。处理块里只要出现一个 raise，检查就会放行，却不会分析每条执行路径是否都能走到它。日志识别也只看方法名，没有验证调用对象是不是 logger。异常类型别名、元组捕获等写法，也不在这段识别逻辑的直接覆盖范围内。

作者展示了一份测试输出：sample_module.py 的第 5 行、第 4 列被标记，silent_swallowing_detected 为 true，has_logging 为 false。这能说明报告格式和定位信息，无法证明误报率、漏报率或实际故障减少了多少。

接入 CI 的示例使用 GitHub Actions，在推送和拉取请求时运行审计：

name: Dependency Exception Audit

on: [push, pull_request]

jobs:
  audit-exceptions:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Run AST Auditor
        run: |
          python -m dependency_exception_auditor

要注意最后一行：执行 python -m dependency_exception_auditor 只是启动程序。发现问题后是否返回非零退出码，决定了它能否真正阻止合并；原文没有展示这部分实现。示例保留了 actions/checkout@v4、actions/setup-python@v5 和 Python 3.12，但这些配置本身并不构成质量门禁。

ASGI 中间件能记录逃出的异常，救不回已经吞掉的异常

运行时方案是在请求边界增加纯 ASGI 中间件。作者设想由 DependencyExceptionAuditorMiddleware 捕获依赖或路由向外抛出的异常，记录完整堆栈和异常层级，再通过 JSONResponse 返回带审计信息的 HTTP 500。

这层防护有用，但要分清它接收到的是什么。

如果数据库提供函数直接抛出 ConnectionError，请求边界就有机会记录原始故障。如果函数已经吞掉异常并返回 None，中间件通常只能看到后来出现的 AttributeError。如果下游恰好容忍 None，请求甚至可能没有异常可捕获。

请求边界可以保住仍在传播的异常，无法凭空恢复已经断掉的因果链。

原文把这一层描述为动态遥测恢复，容易让人以为补上中间件就能兜住吞异常。更准确的理解是：静态检查尝试提前发现危险代码，中间件负责记录最终逃出的错误，两层覆盖的是不同环节。

此外，输入中的实现并不完整。static_audit_source 在 except SyntaxEr 处截断，ASGI 中间件也只有架构描述，没有可检查的完整代码。

所谓兼容性兜底同样需要验证：作者为缺少 orjson、Pydantic 和 FastAPI 的环境安排了替代路径，模型标注兼容 Pydantic v2；但替代 Field 只接收 default 和 description，后面的字段声明却传入 default_factory=list。照展示的代码，在没有 Pydantic 的环境里，这里会发生参数不匹配，无法完成宣称的独立运行。

我的判断

我认同把依赖层的异常传播作为代码审查重点。数据库会话、鉴权结果、租户上下文都属于后续处理的前提，提供失败时继续返回 None，很容易把问题推到更远的位置。

但「记录日志」和「正确处理失败」是两件事。日志留下了证据，不代表下游还能安全执行；反过来，针对明确异常返回约定好的降级结果，也不能一律判成错误。是否应该抛出，要结合依赖契约判断。

相比只靠全局异常处理器，AST 检查能在代码进入运行环境前提示风险；相比完整的控制流分析，这份检查又更粗糙，适合做辅助规则。原文没有提供两种方案的对照数据，效果判断仍属于经验之谈。

它提出的方向可以采用，展示的代码则还不能按「生产可用」直接复制。尤其是完整实现缺失、检查规则与文字不一致、CI 退出行为未展示，这些都会影响实际落地。

能拿来做什么

• 如果项目使用 FastAPI，先检查数据库会话、鉴权和租户依赖里的宽泛 except，明确失败时应该抛出异常，还是返回调用方确实支持的降级结果。
• 接入 AST 审计前，先确定团队规则：仅记录日志是否允许通过。再用包含条件分支、异常别名和合法降级的样例验证检查结果，并确认发现问题会返回非零退出码。
• 验证请求边界日志时，分别模拟依赖直接抛错、依赖吞错后下游报错，检查日志能否保留原始堆栈，避免把捕获到第二次错误误认为恢复了根因。
• 排查接口 500 时，如果日志落在 NoneType 属性访问上，沿着对象的依赖提供链向前找，确认是否有函数捕获异常后返回了 None。