必须用 password_hash() 而非 md5()/sha1()，因其自动加盐、自适应慢哈希且抗彩虹表；验证用 password_verify() 并配合 password_needs_rehash() 按需升级，同时需结合速率限制、双因素等纵深防御。
直接用 password_hash()，别碰 md5()、sha1() 或手写盐值逻辑——它们要么已过时，要么极易出错。
为什么不能用 md5() 或 sha1() 存密码
这两个函数输出固定长度、无盐、计算极快，攻击者用现成的彩虹表或 GPU 暴力几秒就能撞出常见密码。更危险的是，PHP 的弱类型比较会让 "0e123456" == "0e789012" 判定为 true，导致哈希绕过漏洞。
-
md5("123456")是e10adc3949ba59abbe56e057f20f883e，全网可查、不可撤销 -
sha1("password")是5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8，同样毫无防护力 - 即使你手动拼接盐（如
md5($salt . $pass)），也缺乏自适应迭代和密钥派生机制
password_hash() 怎么用才安全
它默认使用 PASSWORD_ARGON2I（PHP 7.2+）或 PASSWORD_BCRYPT（PHP 5.5+），自动加盐、自适应慢哈希，且哈希字符串自带算法、成本因子、盐等元信息，解耦存储与验证逻辑。
- 只传两个参数：
password_hash($password, PASSWORD_DEFAULT)—— 不要硬编码算法名，让 PHP 自动选最新安全方案 - 生成的哈希字符串长度不固定（如 bcrypt 是 60 字符，argon2 是 96+ 字符），数据库字段至少设
VARCHAR(255) - 不要截断、base64 编码或转小写存储，原样存进数据库即可
- 哈希里已含盐，绝不可再额外拼接任何字符串
password_verify() 验证时的常见坑
这个函数内部会解析哈希字符串里的算法、盐、成本参数，自动匹配对应逻辑。但实际使用中容易踩几个隐性雷：
立即学习“PHP免费学习笔记（深入）”；
- 输入密码为空字符串或
null时，password_verify()可能返回false，但不会报错——务必在调用前做非空校验 - 数据库取出来的哈希字段如果被意外 trim() 或 utf8mb4 转码损坏（比如末尾
=被截），验证必然失败，建议用strlen()校验长度是否合理 - 不要用
==比较哈希值本身（比如测试用例里写$hash === password_hash(...)），哈希是随机盐，每次都不一样 - 若升级 PHP 导致
PASSWORD_DEFAULT切换算法（如从 bcrypt 切到 argon2），旧哈希仍可被password_verify()正确识别，无需迁移
什么时候该考虑 password_needs_rehash()
它不是“必须用”，而是“该升级时用”。当用户下次登录，你拿到旧哈希和明文密码后，可以判断是否需要重哈希：
- 触发条件包括：PHP 升级导致
PASSWORD_DEFAULT指向更强算法；或你主动调高了 bcrypt 成本因子（如从cost=10改到cost=12） - 典型流程：
if (password_verify($input, $hash) && password_needs_rehash($hash, PASSWORD_DEFAULT)) { $newHash = password_hash($input, PASSWORD_DEFAULT); /* 存回 DB */ } - 注意：不要在每次登录都无条件重哈希，那会导致同一密码反复生成新哈希，浪费 CPU 且无实质提升
最常被忽略的一点：密码哈希只是第一道防线。如果数据库被拖库，攻击者拿不到明文密码，但能重放登录请求或冒充用户 session。所以 password_hash() 必须配合速率限制、双因素、session 绑定 IP/UA 等手段，单独用它解决不了所有问题。
