必须显式指定method和salt_length、完整保存哈希串、原样传入check_password_hash校验；否则等同明文存储。注册时用generate_password_hash(password, method="pbkdf2:sha256:600000", salt_length=32)，数据库字段至少VARCHAR(255)；登录时check_password_hash须传入未截断、未处理的原始哈希字符串，否则静默返回False。
werkzeug.security.generate_password_hash 和 check_password_hash，但必须显式指定参数、完整保存哈希串、严格按流程校验——否则和明文存储没本质区别。
注册时怎么生成安全哈希
别只传密码，generate_password_hash 必须带 method 和 salt_length：
-
method="pbkdf2:sha256:600000"：明确指定 60 万次迭代，防 GPU 暴力破解；旧版本默认 15 万或 26 万，不够用 -
salt_length=32：比默认 16 字节更抗盐碰撞，且不影响兼容性 - 数据库字段至少设为
String(128)或VARCHAR(255)：pbkdf2 输出约 112 字符，VARCHAR(64)会截断 - 不要自己拼 salt、不要用
hashlib手撸：输出字符串如pbkdf2:sha256:600000$abc123...$xyz789是自解析格式，check_password_hash依赖它还原参数
示例：
from werkzeug.security import generate_password_hash
hashed = generate_password_hash(
password="user123",
method="pbkdf2:sha256:600000",
salt_length=32
)
登录时为什么 check_password_hash 总返回 False
它不报错，只静默返回 False，常见原因全是“看起来正常、实则失效”的细节：
- 数据库里存的不是完整哈希串：比如手动去掉了
pbkdf2:sha256:600000$前缀，或 trim() 过空格/换行 -
User.query.filter_by(email=...)没调.first()，拿到的是 Query 对象，user.password是 None 或 SQL 表达式，不是字符串 - 用户粘贴密码时混入零宽字符（U+200B）、全角空格，
request.form.get("password")拿到的就是脏数据 - 字段类型太短：SQLite 的 TEXT 虽无长度限制，但 PostgreSQL/MySQL 若设成
VARCHAR(64)，哈希被截断后必然校验失败
能不能换用 passlib 的 bcrypt
能，而且更推荐——尤其已有老系统要迁移或对时序攻击敏感：
立即学习“Python免费学习笔记（深入）”；
-
bcrypt天然抗 GPU 暴力，密钥派生更成熟，passlib自动处理盐、轮数、编码格式（如$2b$12$...） - 安装只需
pip install passlib[bcrypt]，不用装全量passlib - 初始化必须用
CryptContext(schemes=["bcrypt"], deprecated="auto")：后者让旧密码登录成功后自动重哈希升级，平滑过渡 - 别写
schemes=["sha256_crypt", "bcrypt"]：混合方案会让 verify 逻辑变复杂，除非真在迁老数据
注意：passlib 和 werkzeug 不兼容——不能用 generate_password_hash 存、pwd_context.verify 校验。
校验逻辑里最容易漏掉的一步
不是算法选错，而是查询路径没兜住边界：
- 先查邮箱是否存在，再校验密码，不能反过来（避免密码爆破枚举）
-
if not user:返回统一错误（如 “邮箱或密码错误”），别分“用户不存在”和“密码错误”，防邮箱枚举 -
check_password_hash必须原样传入数据库读出的字符串，不做任何.strip()、.replace()、正则提取 - POST 方法不可省：GET 会把密码暴露在 URL、日志、代理缓存里
真正卡住人的，从来不是“该不该加盐”，而是哈希串多了一个空格、数据库字段少写了 20 个字符、或者忘了 .first()。
