Flask request，g，session的实现原理

最新推荐文章于 2024-08-22 10:55:19 发布

yueguanghaidao

最新推荐文章于 2024-08-22 10:55:19 发布

阅读量4w

点赞数 12

分类专栏： python

本文链接：https://blog.csdn.net/yueguanghaidao/article/details/39533841

版权

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

摘要由CSDN通过智能技术生成

最近一直在研究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.__name__)