记录一个flask-login的神坑——login_manager.user_loader究竟为什么要写成User.query.get(int(user_id))

login_manager.user_loader究竟为什么要写成User.query.get(int(user_id))

今天在用flask-login做登录的时候出现了一个问题，就是明明我的账号密码都是对的，但是flask-login死活给我跳回登录页面。然后通过检查返回体我发现我的app是正常工作的，是因为登录校验不对才给我跳回登录页面的。我寻思这不对啊我账号密码都对怎么可能呢。
这时候我就想难道是我在login_user的时候登录的对象是None吗，然后开debug模式看了好几遍，数据库查出来的数据是对的。这就很奇怪了。
后来我把目光放在了回调函数上，就是user_loader上，我先放一下我原来的user_loader函数。

@login_manager.user_loader
def load_user(username):
	return User.query.filter_by(username=username).first()

我之所以写成这样是因为觉得id这个字段没有什么用，因为主要都是用username来查询的。
按理说login_user的对象和user_loader查出来的对象一对比就可以了，但是好像login_required死活给我校验得不对。
然后我就去看login_user的源码了，在这里我发现login_user用到了一个session变量，然后login_user往session里面存了user_id

	user_id = getattr(user, current_app.login_manager.id_attribute)()
    session['user_id'] = user_id
    session['_fresh'] = fresh
    session['_id'] = current_app.login_manager._session_identifier_generator()

唔。。。这和我想的不太一样，讲真你不应该把我整个对象存起来吗。然后我就意识到了，login_required的逻辑其实是将user_id传给回调函数，然后如果回调函数查得出东西，login_required就给通过，不行就扔回去登录页面，然后我就看了login_required的源码

def login_required(func):
    @wraps(func)
    def decorated_view(*args, **kwargs):
        if request.method in EXEMPT_METHODS:
            return func(*args, **kwargs)
        elif current_app.login_manager._login_disabled:
            return func(*args, **kwargs)
        elif not current_user.is_authenticated:
            return current_app.login_manager.unauthorized()
        return func(*args, **kwargs)
    return decorated_view

唔。。。居然是个wraps装饰器，讲真其实可读性挺差的，然后我接着找下去发现逻辑太深了就没继续找了。毕竟要考虑时间成本的，所以为了直接验证想法，我把回调函数改成（其实就是网上出现频率最高的回调函数写法，毕竟你们都是你抄我我抄你的，弄得我查找问题的效率特别特别低）

@login_manager.user_loader
def load_user(user_id):
	return User.query.get(int(user_id))

然后跑一下，就登录成功了。唔。。。。果然是这个问题。

写在最后

在解决这个问题的时候我上百度搜的关键字是"flask-login 登录失败"给我出来一堆一模一样的答案，还有个人说自己把user_loader卸载model文件里导致它没生效，然后flask-login报错，我想说我也是把user_loader写在model里，完全没问题，只是他没把LoginManager的实例引入到model里面来而已。
果然这些问题与其上网找答案，还不如自己源码来的简单