最近一直在研究Flask,由于gfirefly中提供的Http接口使用了Flask,以前都是写一些游戏中简单的操作,最近涉及到Flask的方面比较多,所以就认真研究了下。对Flask的request context和app context略有心得,所以和小伙伴们分享一下Flask的request原理。
在我们视图中要使用request时只需要from flask import request就可以了
很好奇在多线程的环境下,是如何保证request没有混乱的
在flask.globals.py中
def _lookup_req_object(name):
top = _request_ctx_stack.top
if top is None:
raise RuntimeError('working outside of request context')
return getattr(top, name)
_request_ctx_stack = LocalStack()
request = LocalProxy(partial(_lookup_req_object, 'request'))
session = LocalProxy(partial(_lookup_req_object, 'session'))
其实可以看到不管request还是session最后都是通过getattr(top, name)获取的,也就是说肯定有一个上下文
对象同时保持request和session。我们只要一处导入request,在任何视图函数中都可以使用request,
关键是每次的都是不同的request对象,说明获取request对象肯定是一个动态的操作,不然肯定都是相同的request。这里的魔法就是_lookup_req_object函数和LocalProxy组合完成的。
LocalProxy是werkzeug.local.py中定义的一个代理对象,它的作用就是将所有的请求都发给内部的_local对象
class LocalProxy(object):
def __init__(self, local, name=None):
#LocalProxy的代码被我给简化了,这里的local不一定就是local.py中定义的线程局部对象,也可以是任何可调用对象
#在我们的request中传递的就是_lookup_req_object函数
object.__setattr__(self, '_LocalProxy__local', local)
object.__setattr__(self, '__name__', name)
def _get_current_object(self):
#很明显,_lookup_req_object函数没有__release_local__
if not hasattr(self.__local, '__release_local__'):
return self.__local()
try:
return getattr(self.__local, self.__nam

本文探讨了Flask框架中的request context、app context以及g对象的实现原理。通过分析源码,解释了如何在多线程环境下确保request对象的正确使用。文章还讨论了LocalProxy和LocalStack的作用,以及为何request使用栈结构来管理。同时,介绍了g对象与app的绑定,强调了不同请求间g对象的独立性。最后,通过模拟多app环境,展示了request context栈的必要性。
最低0.47元/天 解锁文章
1万+

被折叠的 条评论
为什么被折叠?



