flask-security需手动配置关键项才能真正安全：必须先绑定sqlalchemyuserdatastore再初始化security；user/role模型须严格继承mixin并含指定字段；必须显式设置security_password_salt和密码哈希轮次；邮箱确认、登录锁定等功能需同时开启配置与数据库字段支持。
Flask-Security 不是开箱即用的“一键加严”工具，它默认配置偏宽松——比如注册后立即可登录、密码哈希用默认轮次、SECURITY_PASSWORD_SALT 不设就自动生成随机值导致重启后旧密码全失效。真正安全的系统，得靠你主动配置关键开关。
SQLAlchemyUserDatastore 必须在 Security 初始化前完成绑定
这是最常卡住新手的第一步。如果 user_datastore = SQLAlchemyUserDatastore(db, User, Role) 写在 security = Security(app, user_datastore) 之后，Security 构造时会立刻调用 user_datastore.find_role()，而此时 db 和模型还没绑定好，直接抛 AttributeError: 'NoneType' object has no attribute 'query'。
实操要点：
-
db = SQLAlchemy(app)必须在定义User、Role模型前执行（否则db.Column找不到元数据） -
User类必须继承UserMixin，字段名严格为email、password、active；Role类必须继承RoleMixin，含name字段 -
user_datastore实例化后，首次运行前务必调用user_datastore.db.create_all()或用Flask-Migrate建表
密码哈希与 salt 配置不匹配会导致旧密码批量失效
默认 SECURITY_PASSWORD_HASH = 'bcrypt' 是安全的，但若漏掉 SECURITY_PASSWORD_SALT，Flask-Security 会在每次应用启动时生成新 salt，所有已存密码验证失败——这不是 bug，是设计行为，但生产环境绝对不能接受。
正确做法：
- 显式设置固定
salt：app.config['SECURITY_PASSWORD_SALT'] = 'your-24-byte-secret-here'（长度 ≥24 字节，建议用os.urandom(24).hex()生成） - 如需更高强度，调高 bcrypt 轮次：
app.config['SECURITY_BCRYPT_LOG_ROUNDS'] = 14（默认 12） - 切勿手动
generate_password_hash()后再传给create_user()——user_datastore.create_user(password='plain')会自动哈希
邮箱确认、登录锁定等“加严”功能需显式开启并配全依赖
SECURITY_CONFIRMABLE = True 单独设置没用。用户注册后仍能直接登录，除非同时满足：数据库有 confirmed_at 字段、模板里渲染了确认邮件链接、且后端路由处理了 /confirm/<token></token>。
同理，登录失败锁定（SECURITY_TRACKABLE + SECURITY_LOGIN_THRESHOLD）要求 User 模型带 login_count、last_login_at、current_login_at、current_login_ip、last_login_ip 字段，缺一个就静默失效。
关键配置项：
-
SECURITY_REGISTERABLE = True（允许注册） -
SECURITY_CONFIRMABLE = True（强制邮箱确认） -
SECURITY_TRACKABLE = True（启用登录追踪） -
SECURITY_LOGIN_THRESHOLD = 5（5 次失败后锁定） -
SECURITY_LOGIN_WITHOUT_CONFIRMATION = False（确认前禁止登录）
@roles_required 装饰器在蓝图中失效的常见原因
把 @roles_required('admin') 加在蓝图路由上却没生效？大概率是 Security 初始化太晚，或蓝图注册顺序不对。装饰器依赖 current_user 和内部权限检查器，而这两者由 Security 在 app.before_first_request 阶段注入。
排查步骤：
- 确认
security = Security(app, user_datastore)在所有蓝图register_blueprint()之前执行 - 检查是否误用了
@login_required（只校验登录态）而非@roles_required（校验角色） - 模板中用
{% if current_user.has_role('admin') %}时，确保current_user已加载（避免在未登录上下文里调用）
SECURITY_CONFIRMABLE 就得自己搭 SMTP 服务或集成 Mailgun；启用登录锁定就得定期清理过期失败记录——这些细节不写进代码，光靠文档是撑不起生产环境的。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
