UserMixin是Flask-Login提供的混入类，通过继承即可自动实现is_authenticated、is_active、is_anonymous和get_id()四个必需方法，使用户模型快速兼容认证系统；其中get_id()须返回字符串类型ID，否则current_user为None。
Flask-Login 的 UserMixin 是怎么用的？
UserMixin 提供了 is_authenticated、is_active、is_anonymous 和 get_id() 这几个必需属性/方法，是让自定义用户类快速兼容 Flask-Login 的最简路径。它不处理数据库，只负责接口契约。
- 必须确保你的用户模型（比如
User类）继承UserMixin，否则login_user()会报AttributeError: 'User' object has no attribute 'is_authenticated' -
get_id()默认返回self.id，但要求返回值是字符串——如果数据库主键是整型，得手动转成str(self.id)，否则登录后current_user始终为None - 不要覆盖
is_authenticated为 property 并抛异常，Flask-Login 依赖它做内部判断；有特殊逻辑（如封禁检查）应放在is_active里
为什么 login_user() 后 current_user 是 AnonymousUserMixin？
这不是代码没执行，而是会话未正确持久化或用户对象未通过 Flask-Login 认可。常见原因有：
-
app.secret_key没设置，导致 session 签名失败，每次请求都新建匿名会话 - 用户对象的
get_id()返回了None或非字符串（比如直接返回整数123而不是"123"） - 使用了数据库 ORM（如 SQLAlchemy），但用户查出来后被 session close 或 detach，
current_user在后续请求中无法重建——确保查询时用db.session.merge()或保持 session 活跃 - 登录视图里忘了调用
login_user(user)，或者调用了但后面又重定向前写了return语句提前退出
如何安全地限制未登录用户访问路由？
别手写 if not current_user.is_authenticated: 判断——既啰嗦又容易漏。用 @login_required 装饰器才是标准做法。
- 它自动检查
current_user.is_authenticated，不满足就重定向到login_manager.login_view指定的端点 - 可以在
LoginManager初始化后设置跳转参数：login_manager.login_view = 'auth.login'，并支持带 next 参数的回跳：login_manager.login_message = '请先登录' - 如果某个路由允许登录/未登录用户都访问，但行为不同，就不要加装饰器，直接用
current_user.is_authenticated分支即可 - 注意：装饰器必须放在
@app.route下方，否则不生效；顺序错了会导致 404 或装饰器被绕过
logout_user() 为什么没清掉 session 数据？
logout_user() 只清除 Flask-Login 维护的用户上下文（如 _user_id、_fresh 等），不会清空整个 session 字典。这是设计使然，不是 bug。
立即学习“Python免费学习笔记（深入）”；
- 如果你存了自定义数据（如
session['cart_items']），登出后依然存在；需要手动删：session.pop('cart_items', None) -
remember_token（记住我功能）由 Flask-Login 自动管理，调用logout_user()会一并清理，无需额外操作 - 若登出后还能通过 URL 直接访问需鉴权的页面，大概率是浏览器缓存了响应，加个
@app.after_request设置Cache-Control: no-store更稳妥
Flask-Login 本身不加密、不传输、不存储密码，它只管“谁当前被认定为已登录”这件事。真正复杂的点永远在用户加载函数——user_loader 回调里查库是否够快、会不会 N+1、是否用了正确的主键类型，这些不解决，再好的会话管理也撑不住真实流量。
