WSGI迁移FastAPI：ASGI中间件与同步路由等技术问题咨询

背景概述 #

现有架构基于原WSGI应用迁移，包含以下组件：

• 异常捕获ASGI中间件
• 解析请求凭证并存储至threading.local()的ASGI中间件
• 管理数据库会话并捕获数据库异常的ASGI中间件
• 遗留路由异步处理器：转换Starlette请求参数后同步调用旧路由

遗留端点测试正常，但新增原生同步路由时，因路由在独立AnyIO线程执行，无法获取中间件解析的用户凭证，以下是核心问题解析：

问题1：异步路由处理器运行带数据库IO的遗留同步路由，是否会影响性能？ #

• 会产生明显性能损耗。FastAPI/Starlette会将同步逻辑（包括异步处理器内调用的同步路由）放入AnyIO线程池执行，同步数据库IO会阻塞线程池线程。高并发场景下，线程池被占满后，后续请求会排队等待，直接降低整体吞吐量。
• 优化方向：短期可调整AnyIO线程池大小（如启动时设置--workers参数或配置AnyIOConfig）缓解压力；长期建议逐步将数据库操作替换为异步驱动（如用asyncpg替代psycopg2）。

问题2：threading.local()是否对单个异步路由保持本地性？FastAPI传递请求数据的标准方式？ #

• threading.local()不适用异步场景：异步任务可能在不同线程间调度切换，而threading.local()与线程绑定，同步路由在独立线程执行时，会丢失原线程中间件存入的数据，这就是凭证获取失败的原因。
• 标准传递方案：
  • Starlette Request的state属性：中间件中直接将数据存入request.state.user = 解析后的凭证，路由函数通过request.state.user获取。
  • 依赖注入：将凭证解析逻辑封装为依赖，路由函数直接声明依赖获取数据，更符合FastAPI设计理念，同时支持异步/同步场景。

问题3：生成器依赖中yield后提交数据库异常不影响响应？是否需显式提交？ #

• 该现象合理：FastAPI生成器依赖的执行逻辑为：yield前代码在请求处理前执行，yield返回的对象供路由使用，yield后代码在响应发送给客户端后才执行（属于请求清理阶段），因此此时的异常无法修改已发出的响应。
• 处理建议：
  • 不要在yield后执行提交操作，应在路由函数中显式提交（或封装为装饰器/专用依赖），这样可在提交失败时捕获异常，返回正确的错误响应。
  • 若需在依赖中处理事务，可使用上下文管理器风格的依赖，在请求处理过程中完成提交/回滚，确保异常能被捕获并反馈给客户端。

问题4：add_exception_handler()无法捕获ASGI中间件中的异常？ #

• 该现象正确：FastAPI的add_exception_handler()仅能捕获**路由处理阶段（含依赖、路由函数）**的异常。ASGI中间件处于FastAPI路由处理流程之外（属于ASGI协议栈更早阶段），因此这类异常无法被FastAPI的异常处理器捕获。
• 处理方式：ASGI中间件的异常需在中间件内部自行捕获处理，或使用Starlette的ExceptionMiddleware（FastAPI默认集成）捕获全局ASGI层面的异常。

问题5：还应关注哪些相关问题？ #

• 并发模型差异：WSGI为同步阻塞模型，每个请求对应一个线程；ASGI为异步非阻塞模型，单个进程可处理大量并发请求，需排查原有同步代码的阻塞点（如文件IO、第三方同步调用），避免影响整体性能。
• 线程/协程安全：原有基于threading.local()的代码需替换为协程安全的存储方案（如contextvars，FastAPI的request.state底层基于此实现），防止数据污染。
• 异步测试适配：异步路由测试需使用AsyncClient而非普通TestClient，确保测试环境模拟真实异步运行场景。
• 中间件顺序：ASGI中间件执行顺序为添加顺序从外到内，与WSGI中间件顺序相反，需调整中间件顺序，确保异常捕获、凭证解析等逻辑执行顺序正确。
• 遗留代码兼容性：若遗留代码依赖WSGI的environ对象，需确保转换后的请求数据完全兼容，避免参数丢失、格式错误等问题。

内容的提问来源于stack exchange，提问作者expatriate