Django默认用PBKDF2+SHA256哈希密码，格式为$pbkdf2_sha256$轮数$盐$哈希值；升级算法只需修改PASSWORD_HASHERS配置并依赖登录时自动迁移，不可手动用hashlib或批量重算。
直接用 make_password() 和 check_password() 就够安全，别自己调 bcrypt 或 hashlib；升级哈希算法靠改 PASSWORD_HASHERS 配置 + 登录时自动迁移，不是批量重算数据库。
为什么不能手动用 hashlib.sha256 存密码
因为 hashlib.sha256 是通用哈希，没加盐、没迭代、计算太快——攻击者用 GPU 一秒钟能试几亿次。你写 sha256(salt + password) 看似加了盐，但盐怎么存？怎么保证每次验证用同一个盐？怎么控制耗时防暴力？全得自己兜底，漏一处就等于裸奔。
- 生成的哈希字符串不含元信息（盐、轮数、算法标识），验证时无法复现过程
- 没有恒定时间比较，
==比对会暴露时序差异，可能被用于侧信道攻击 - Django 的
authenticate()、check_password()完全不认这种格式，没法接入原生流程
Django 默认怎么存密码：看懂 $pbkdf2_sha256$260000$ 开头的字符串
Django 用户的 password 字段值长这样：pbkdf2_sha256$260000$abc123...$def456...。这不是乱码，是结构化存储：算法名、迭代次数（260000）、盐、哈希值，全部用 $ 分隔。
-
pbkdf2_sha256表示当前用 PBKDF2+SHA256，默认且推荐，平衡安全与性能 -
260000是迭代轮数（work factor），数值越高越慢越安全，但也越吃 CPU - 每次调
make_password("123")输出都不同，因为盐是随机生成的 - 验证时
check_password("123", user.password)会自动解析字符串、提取盐、按对应轮数重算并恒定时间比对
想换 Argon2 或 bcrypt：改 PASSWORD_HASHERS 并允许旧密码兼容
Argon2 是密码哈希竞赛冠军，内存硬性设计抗 ASIC；BCryptSHA256PasswordHasher 也比默认更抗暴力。但切换不是“一刀切”，要让老用户下次登录时自动升级。
立即学习“Python免费学习笔记（深入）”；
- 在
settings.py中把新算法放PASSWORD_HASHERS列表首位：PASSWORD_HASHERS = [ 'django.contrib.auth.hashers.Argon2PasswordHasher', 'django.contrib.auth.hashers.PBKDF2PasswordHasher', 'django.contrib.auth.hashers.BCryptSHA256PasswordHasher', ] - 老用户仍可用原密码登录——Django 会识别他们密码开头的
pbkdf2_...，用第二项解码验证 - 验证成功后，
authenticate()或set_password()会自动用第一项（Argon2）重新哈希并存回数据库 - 不需要跑数据迁移脚本，也不该用 raw SQL 批量 update —— 那会强制登出所有用户，且跳过信号和校验逻辑
自己写密码逻辑时最容易踩的三个坑
哪怕只是临时调试或对接遗留系统，只要碰密码处理，这三个点几乎必错。
-
make_password()返回的是str，但有些 ORM（如 SQLAlchemy 配合某些字段类型）要求 bytes，存之前别忘.encode("utf-8")；反过来，从 DB 读出的bytes传给check_password()前得.decode("utf-8") - 用
user.set_password(new_pwd)后必须调user.save()，否则哈希不落地；而create_user()内部已包含 save，不用额外调 - 修改密码页面里，如果用
request.user.check_password(old_pwd)验证旧密码，别漏掉old_pwd是 str，得确保它没被意外转成 bytes 或 None
最常被忽略的其实是“升级不是立刻生效”——新算法只对新注册和下次登录的用户起效，数据库里混存多种哈希格式是正常且预期的行为；强行统一反而破坏安全链路。
