### 从Python ASGI看异步时代的Web接口规范
1. 它是什么
要说ASGI，得先从WSGI说起。十年前写Python Web应用时，Django、Flask用的都是WSGI——一个同步的网关接口规范。它像是一条单向车道，每次只能处理一个请求，处理完了才能接下一个。这在当年够用，但遇到长连接、WebSocket这类需要保持连接的东西，WSGI就暴露了它的局限性：它压根没设计过要处理这种场景。
ASGI（异步服务器网关接口）就是为解决这个问题而生的。它把WSGI的“请求-响应”模型，扩展成更通用的“事件-响应”模型。简单说，ASGI不只是处理HTTP请求，它能处理各种类型的消息：HTTP请求是消息，WebSocket连接是消息，甚至服务器推送也是消息。
如果把WSGI比作传统的邮局——你得排着队等着窗口处理你的挂号信，那ASGI就像微信——你可以同时开多个会话，每个会话保持连接，随时收发消息。当然不是简单地多开几个窗口，而是协议层面完全不同的设计。
ASGI规范的核心是两个组件：协议服务器和应用程序。协议服务器（比如Uvicorn、Daphne）负责解析网络上的字节流，把它转成ASGI能理解的“scope”（连接信息）和“events”（事件流）。应用程序就是你的业务逻辑，它接收这些事件，做出响应。
这种分层设计的妙处在于：你可以在同一个应用里处理HTTP请求、WebSocket连接、甚至SSE（服务端推送），而且这些连接互不阻塞。这在WSGI时代几乎是不可能的。
2. 它能做什么
ASGI最直接的好处就是处理高并发I/O密集型任务。比如一个聊天应用，成千上万个WebSocket连接同时保持，如果有消息广播，ASGI可以高效地通知所有连接的客户端，而不需要为每个连接开一个线程。
另一个常见场景是实时数据推送。比如说股票行情页面，后端数据一变，前端要马上更新。用ASGI的SSE机制，可以省去前端轮询的麻烦，而且带宽利用率更高。
还有前后端能共享逻辑。如果前端需要用户认证，用ASGI可以把认证逻辑放在同一层处理，不管是HTTP请求还是WebSocket连接，都能走同一套认证方案。这在微服务架构下尤其有用，因为可以减少内部调用的复杂度。
不过要注意，ASGI不是万能的。它擅长的是I/O密集型的任务，如果是计算密集型的（比如大型图像处理、复杂的数据分析），用ASGI反而会因为协程切换和任务调度的开销降低性能。这种情况更适合用Celery这类任务队列。
3. 怎么使用
使用ASGI通常需要三样东西：一个ASGI服务器（比如Uvicorn），一个ASGI框架（比如FastAPI、Starlette、Django Channels），以及你的应用代码。
先看个最简单的例子。一个返回JSON的ASGI应用，可不借助任何框架：
asyncdefapp(scope,receive,send):ifscope['type']=='http':awaitsend({'type':'http.response.start','status':200,'headers':[(b'content-type',b'application/json')],})awaitsend({'type':'http.response.body','body':b'{"message": "hello"}',})然后运行uvicorn app:app，就能看到结果了。但说实话，谁会这么写应用呢？实际开发中都用框架。
用FastAPI写个更实际的例子：
fromfastapiimportFastAPI,WebSocketfromfastapi.responsesimportStreamingResponseimportasyncio app=FastAPI()@app.get("/")asyncdefroot():return{"message":"Hello World"}@app.websocket("/ws")asyncdefwebsocket_endpoint(websocket:WebSocket):awaitwebsocket.accept()whileTrue:data=awaitwebsocket.receive_text()awaitwebsocket.send_text(f"Echo:{data}")@app.get("/stream")asyncdefstream():asyncdefgenerate():foriinrange(10):yieldf"data:{i}\n\n"awaitasyncio.sleep(1)returnStreamingResponse(generate(),media_type="text/event-stream")这个例子展示了ASGI的三种典型场景：正常HTTP请求、WebSocket连接、SSE流式响应。注意看，三个endpoint共享同一个服务器进程，但不会彼此阻塞。每个endpoint里都有await，这说明它们虽然看起来是“同时运行”，但底层依托的是事件循环的协作式调度，并不是真正的并行。
这里有个容易踩的坑：如果你在异步视图里调用了同步的库（比如requests.get），这会导致整个事件循环被阻塞。解决办法是用asyncio.to_thread把同步调用丢到线程池里去跑，或者换用支持异步的库（比如httpx）。
4. 最佳实践
选择合适的服务器。Uvicorn性能最好，适合生产环境；Daphne是Django Channels的官方选择，如果你用Django，它会更顺手；Hypercorn支持HTTP/2，如果要兼容某些特定协议，可以考虑它。个人经验是，大多数情况用Uvicorn就够了。
谨慎处理长连接。WebSocket和SSE这种长连接会长期占用资源，如果应用负载很高，要考虑限流。可以用Redis来做全局的连接统计，当某个用户的连接数超过阈值时拒绝新的连接。另外，对于WebSocket，记得在连接断开时清理资源——有些人会忘记写try/finally，导致连接断开后协程还一直跑着。
异步数据库驱动是必需的。如果数据库查询是同步的，那么ASGI的异步优势就荡然无存了。最常用的选择是asyncpg（PostgreSQL）和aiomysql，ORM层面可以用SQLAlchemy的异步模式，或者用GINO。但注意，很多ORM的异步支持还不完善，比如Django的ORM虽然支持异步，但查询集的操作还是同步的，得用sync_to_async包一层。
事务管理需要小心。在同步世界里，事务的范围很清楚：开始、操作、提交或回滚。但在异步环境下，如果协程中途被挂起，事务的隔离性可能出问题。一个简单的做法是在需要事务的地方显式地用async with管理连接，而不是依赖隐式的事务管理。
合理设置并发限制。ASGI应用默认可以处理大量并发，但这不意味着你可以无限制地开协程。每个协程都有内存开销，并发量太大一样会撑爆内存。一般生产环境会配合负载均衡器（比如Nginx）来限流，或者在应用层用Semaphore来控制最大并发数。
监控工具要跟上。传统的APM工具对异步的支持参差不齐。排查性能瓶颈时，如果看的是异步代码的调用栈，经常让人摸不着头脑。推荐用asyncio自带的调试模式（PYTHONASYNCIODEBUG=1），或者用asyncpg这类库自带的日志，能让你看到每个查询的具体耗时。
5. 和同类技术对比
先说WSGI。这是ASGI出现前的事实标准。Flask、Django（通道除外）都是基于WSGI的。WSGI的优点在于简单、稳定、生态完善，几乎所有的Python Web库都兼容它。缺点就是前面说的：同步模型，处理不了WebSocket，也处理不了高并发的长连接。如果现有项目没有实时交互的需求，用WSGI完全可以，没必要强行上ASGI。但新项目我倾向于推荐ASGI，因为它的弹性更好，将来想加个WebSocket功能不用重构。
再说Node.js。Node.js自身就是事件驱动、异步非阻塞的，和ASGI的理念很像。Node.js用单线程的事件循环处理大量并发，胜在JIT编译的V8引擎，简单I/O任务性能比Python强。但Python的优势在于生态——数据科学、机器学习、运维自动化，这些库大部分是Python的。如果团队里有不少人写Python，用ASGI统一技术栈，能减少上下文切换的成本。
然后是Go。Go用的是Goroutine，是真正的并发（多线程并行），而不是Python的协程（单线程并发）。这意味着Go在处理CPU密集型任务比ASGI有优势。但Go的Web框架生态不如Python丰富，如果你依赖ORM、管理后台、认证中间件这些现成的东西，Go会让你多写不少代码。
还有Java的Netty（或者Spring WebFlux）。它也是异步非阻塞的，性能比ASGI好，特别是在长时间运行的连接上，内存管理比Python好太多。但Java的学习曲线比Python陡峭，开发效率也低一些。对于大部分业务场景，Python的ASGI在开发效率和性能之间找到了一个还不错的平衡点。
最后想说一下移动端。ASGI并不是为移动端设计的，但如果你用WebSocket和移动端通信，ASGI的异步模型天然适合这种场景。有些团队用ASGI做后端，用Flutter或React Native做客户端，WebSocket是全双工的，体验上很像原生应用的实时通信。# ## 谈谈Python里的中间件
写Python时间长了，总会遇到一些让自己纠结的设计问题。比如一个请求进来，要在正式处理之前做权限校验、日志记录、性能监控，这些代码如果全部塞进业务逻辑里，用不了多久，代码就会乱成一锅粥。这就是为什么很多人最终会接触到中间件。
中间件是什么
本质上，中间件就是一个处理请求的管道。想象一下快递公司送货的过程，包裹从收货到最终送上门，会经过分拣、扫描、清关、配送站等环节。每个环节只做自己的事，互不干扰。中间件就是Web框架里的这些“环节”，它们串联成一个处理链，每个中间件拿到请求，做一些事情，然后传给下一个，直到抵达真正的业务处理函数。
在Python的Web框架里，这个模式特别常见。Django有MIDDLEWARE列表，Flask有before_request和after_request，FastAPI则直接继承了Starlette的中间件机制。不管是哪个框架，核心思路都差不多：把横切关注点（cross-cutting concerns）剥离出来，让业务代码干干净净。
中间件能做什么
有个场景很典型。公司有个老系统，所有接口都返回JSON，但突然有一天安全部门要求所有API都要记录请求来源IP、耗时、返回状态。如果去改每个视图函数，工程量巨大还容易出错。用中间件的话，写一个请求日志中间件，挂上去，问题就解决了。
还能做很多事情。比如API限流，判断单位时间内某个IP的请求次数；比如CORS跨域设置，在响应头里加上Allow-Origin；比如统一的异常捕获，把框架抛出的错误转换成统一的JSON格式；还有请求参数预处理、响应数据压缩、数据库事务管理。这些都是中间件的用武之地。
有个小技巧，中间件还可以用来做A/B测试。根据请求携带的特定标识，在中间件里切分流量，把不同版本的响应返回给用户。这种需求直接在业务代码里写，会让代码变得很难维护。
怎么使用中间件
用Django举个例子，在settings.py里加上：
MIDDLEWARE=['django.middleware.security.SecurityMiddleware','django.contrib.sessions.middleware.SessionMiddleware','django.middleware.common.CommonMiddleware','myapp.middleware.RequestLogMiddleware',]写一个自定义中间件，Django支持两种写法。一种是函数式：
defsimple_middleware(get_response):defmiddleware(request):# 请求进来时执行的代码response=get_response(request)# 响应出去时执行的代码returnresponsereturnmiddleware另一种是类形式：
classRequestLogMiddleware:def__init__(self,get_response):self.get_response=get_responsedef__call__(self,request):start_time=time.time()response=self.get_response(request)duration=time.time()-start_time logger.info(f"{request.path}took{duration:.2f}s")returnresponseFastAPI的中间件稍微有点不同，用装饰器或者直接注册中间件类：
@app.middleware("http")asyncdefadd_process_time_header(request:Request,call_next):start_time=time.time()response=awaitcall_next(request)process_time=time.time()-start_time response.headers["X-Process-Time"]=str(process_time)returnresponse一些实践经验
中间件写多了，会发现有几个坑特别容易踩。一个是中间件的顺序问题。比如把权限校验中间件放在静态文件中间件前面，静态文件也要走一遍权限校验，明显不合理。另一个是中间件里不要做耗时操作，比如发HTTP请求、查数据库。中间件会被每一个请求调用，如果效率低，整个服务都会被拖慢。真要这么做，确保加了缓存或者异步处理。
还有个容易被忽略的点：中间件里抛出的异常。如果中间件里出了问题，又没有妥善处理，框架的异常中间件可能根本捕获不到。所以最好在自定义中间件里加上全面的try-except，或者确保框架的异常处理中间件排在最外层。
跟其他技术比起来
有同事问过，中间件和装饰器有什么区别。装饰器也能做类似的事，比如在每个视图函数上加@login_required。问题在于，装饰器得每个函数都手动加，一不小心就会漏掉。中间件是全局生效的，不会出现“这个接口忘了加权限校验”的情况。如果确实需要某些接口跳过中间件的处理，在中间件内部判断路径就好了。
还有AOP（面向切面编程），这是Java里的概念。Python里虽然没有原生的AOP，但中间件其实就是在实现AOP的核心思想：把横切逻辑剥离出来，在合适的地方织入。只是Python的中间件更加简洁，不需要复杂的注解和代理模式。
至于WSGI中间件，这是更底层的概念。比如用Flask开发的Web应用，其实本身就有一层WSGI中间件。Django也类似，django.core.handlers.wsgi.WSGIHandler就是最外层的WSGI应用。框架层面提供的中间件机制，实际上是建立在这层之上的更高层抽象。日常开发中，用框架自带的中间件机制就足够了，不需要直接去操作WSGI层面。
实际开发中最常见的情况是，代码写到一半，发现某个逻辑需要横跨多个视图。这时候停下来想想，是不是可以用中间件。把它从业务代码里抽出来，放到中间件里，不仅代码变得整洁，以后要改也方便。这个判断，往往就是区分好代码和凑合能跑的代码的分界线。
总的来说，ASGI不是万能钥匙，但它解决了Python Web生态里一个长期存在的痛点：如何在一个进程里优雅地处理多种类型的连接。对于还需要处理实时数据、消息推送、WebSocket的Python Web应用来说，ASGI是目前最成熟的方案了。如果你现在还在用WSGI，可以考虑给自己的应用加个ASGI网关层慢慢过渡——不必一下子全改，但值得尝试。
