django默认使用pbkdf2而非argon2或bcrypt，因其零依赖、nist合规、迭代与salt可扩展，且默认26万次迭代兼顾安全与性能；make_password和check_password均动态读取password_hashers[0]，支持渐进式算法迁移。
PBKDF2 是 Django 默认密码哈希算法，因为它在安全性、兼容性与可配置性之间取得了最务实的平衡。
为什么不是更“新”的 Argon2 或 bcrypt？
Django 并不排斥 Argon2 或 bcrypt —— 它们都在 PASSWORD_HASHERS 列表里，默认启用且可用于验证旧密码。但默认存储仍选 PBKDF2，原因很实际：
- Argon2 虽然抗 GPU/ASIC 更强，但需要额外安装
argon2-cffi依赖，而 PBKDF2 是 Python 标准库hashlib原生支持的，零依赖、开箱即用 - bcrypt 在内存占用和并行度控制上不如 Argon2 灵活，且其 salt 长度固定（22 字符 base64），而 PBKDF2 的 salt 和迭代次数都可自由扩展
- PBKDF2 + SHA256 是 NIST 正式推荐的标准（SP 800-132），审计合规场景中更容易通过安全评估
- Django 的迭代次数默认设为 260000（2026 年仍有效），这个值在现代 CPU 上验证耗时约 100ms，既防暴力又不拖慢登录体验
make_password 和 check_password 怎么依赖 PBKDF2？
这两个函数不硬编码算法，而是读取 PASSWORD_HASHERS[0]。只要你不改 settings，make_password('xxx') 就会输出形如 pbkdf2_sha2560000$abc123...$hash 的字符串；check_password 则自动解析前缀，调用对应 hasher 的 verify() 方法。
这意味着：
- 你手动调用
make_password('pwd', None, 'argon2')是完全合法的，但数据库字段仍能被check_password正确识别和验证 - 如果某天你把
Argon2PasswordHasher移到PASSWORD_HASHERS第一位，所有新注册用户就自动切到 Argon2，老用户密码仍可用旧算法验证 —— 迁移是渐进的 - 不要试图从
user.password字段里“解密”或“还原”原始密码，它根本不可逆；字段值里的$分隔结构只是 hasher 的元数据，不是加密容器
什么时候该主动换掉默认 PBKDF2？
换算法不是升级，而是权衡。常见触发场景包括：
- 你的应用处理高价值账户（如金融、医疗后台），且服务器内存充足 → 可切换到
Argon2PasswordHasher，重点提升抗硬件攻击能力 - 你正在对接遗留系统，要求必须兼容 bcrypt 输出格式（例如
$2b$12$...）→ 把BCryptSHA256PasswordHasher放到PASSWORD_HASHERS首位 - 你在嵌入式或低配环境部署 Django（比如树莓派），PBKDF2 的 260000 次迭代导致登录延迟明显 → 可自定义一个迭代数更低的
PBKDF2PasswordHasher子类（但别低于 60000） - 你发现日志里频繁出现
ValueError: Unknown password hashing algorithm→ 说明数据库里存了非标准 hasher 的密码，而它没被列入PASSWORD_HASHERS，必须补全
真正容易被忽略的是：PBKDF2 的安全性高度依赖迭代次数是否随硬件演进同步上调。Django 每次大版本会悄悄提高默认值（比如 2.2 是 100000，3.2 是 150000，当前 260000），但如果你长期冻结 Django 版本或手动覆盖了 PASSWORD_HASHERS，这个关键参数就可能停滞不动。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
