fastapi:父子应用的全局异常处理

一，父子应用对异常的处理机制:

在 FastAPI 中，针对挂载（Mount）了子应用（Sub-applications）的架构，全局异常处理机制在父应用和子应用之间的行为是隔离的。

为什么父应用的异常处理对子应用“失效”？

当你在父应用上使用 @app.exception_handler 时，它只能捕获直接在父应用路由中抛出的异常。

对于通过 app.mount("/admin", admin_app) 挂载的子应用：

1. 请求路由阶段：当请求进入 /admin/... 时，父应用仅仅充当一个路由转发器的角色，将整个 ASGI 生命周期的控制权完全交给了 admin 子应用。
2. 异常发生阶段：异常是在子应用内部触发的。子应用会尝试在自己的异常处理器中寻找匹配项。
3. 后备机制（Fallback）：如果子应用没有捕获该异常，它会遵循 ASGI 规范向上抛出（Bubble up）。
   此时父应用虽然能感知到有异常发生（通常是报错或者触发父应用最外层的中间件），但由于上下文已经属于子应用，父应用的 FastAPI 异常处理器（Exception Handlers）无法拦截并修改子应用的 Response。

二，正确处理方式：

最佳实践是：分别针对 front和 admin 子应用配置异常处理 。

这样做不仅符合 FastAPI/Starlette 的设计哲学，还能带来巨大的架构优势：
由于前台（Front）和后台（Admin）面向的用户群体不同，它们往往需要截然不同的错误响应格式。

 

子应用：

front_app = FastAPI(title="我的API项目")

# 🚀 注册中间件
# api_app.add_middleware(SignatureMiddleware)
_register_exception_handlers(front_app)
# 注册路由模块
front_app.include_router(index_router)

父应用：

    app.mount("/front", front_app)  # 所有 /front/* 路由交由 front_app 处理
    app.mount("/admin", admin_app)  # 所有 /admin/* 路由交由 admin_app 处理
    return app