更多内容请见： 《Python Web项目集锦》 - 专栏介绍和目录
文章目录
- 前言：历史的分水岭
- 第一章：认知升级——从 WSGI 到 ASGI 的底层跃迁
- 1.1 WSGI 的“同步枷锁”
- 1.2 ASGI 的“异步解放”
- 第二章：基础设施换血——告别 Werkzeug，拥抱 ASGI 服务器
- 2.1 为什么异步视图不能用 Gunicorn (sync worker)？
- 2.2 三大 ASGI 服务器选型
- 第三章：核心语法——在 Flask 中编写第一个异步视图
- 3.1 基础的异步 GET 视图
- 3.2 异步 POST 视图与 JSON 解析
- 第四章：跨越边界——原生协程与第三方异步库的整合
- 4.1 请求外部 API：从 `requests` 到 `httpx` 或 `aiohttp`
- 4.2 数据库驱动：从 `psycopg2` 到 `asyncpg` 或 `SQLAlchemy 2.0`
- 第五章：并发利器——在视图内触发多个独立任务
- 第六章：混合编程艺术——`sync` 与 `async` 视图的共存法则
- 6.1 无缝共存机制
- 6.2 Background Tasks（后台任务的异步执行）
- 第七章：避坑指南——异步 Flask 的“致命反模式”
- 7.1 “假异步”陷阱（最普遍的错误）
- 7.2 阻塞事件循环的 CPU 密集型任务
- 7.3 SQLAlchemy 的 Session 陷阱
- 第八章：极限压测——异步 vs 同步的真实性能对比
- 结语：拥抱异步，重塑 Web 架构
前言：历史的分水岭
在漫长的 Web 开发历史中，Python 一直背负着一个沉重的标签：“并发性能低下”。这种偏见的根源，深植于 Python 最广泛使用的 WSGI 协议（PEP 3333）以及 CPython 解释器的 GIL（全局解释器锁）。传统的 WSGI 要求服务器必须完全接收并处理完一个请求后，才能释放线程去处理下一个请求。这意味着，如果你的 Flask 视图函数中有哪怕一微秒的同步阻塞（如查询数据库、请求外部 API、读写文件），当前线程就会像被胶水粘住一样停滞不前。
为了突破这个瓶颈，开发者不得不求助于 Gunicorn 的gevent或eventlet，通过猴子补丁去篡改 Python 标准库底层极其脆弱的网络 Socket。这种“旁门左道”虽然在一定程度上提升了并发，但极易引发极其诡异的第三方库兼容性灾难。直到 2021 年，Flask 2.0 的发布，犹如一声春雷，彻底终结了这个混乱的时代。
Flask 2.0 基于全新的ASGI（Asynchronous Server Gateway Interface）协议（PEP 3333 的继任者），从底层架构上原生支持了 Python 3.7+ 的async/await协程特性。这标志着 Flask 正式跨入了异步时代。本文将带你深入底层协议，剥开async def的神秘面纱，全面掌握在 Flask 中编写高性能异步视图的终极奥义。
