应使用password_hash()和password_verify()函数安全存储验证密码，禁用md5/sha1等弱哈希及手动加盐；默认用PASSWORD_DEFAULT自动适配最优算法，数据库字段需设VARCHAR(255)以兼容所有哈希长度。
直接用 password_hash() 生成哈希值，存进数据库即可；别碰 md5()、sha1() 或手动拼 salt —— 这些不是“不够好”，而是已经失效。
为什么不能用 md5() 或 sha1() 存密码
它们是通用哈希函数，不是为密码设计的：计算太快、不加盐、抗碰撞能力差。现在一张消费级显卡每秒能跑上亿次 md5() 碰撞，彩虹表库也早把常见组合全预计算好了。哪怕你加了 salt，只要算法本身可高速穷举，就等于没设防。
常见错误现象：
- 数据库里看到一堆
5f4dcc3b5aa765d61d8327deb882cf99这类固定长度 32 位字符串 —— 基本就是裸md5() - 登录逻辑里出现
md5($_POST['pass'] . $row['salt']) === $row['password']—— 手动 salt 管理极易出错，且无法随硬件升级自动增强强度
password_hash() 的参数怎么选
默认调用 PASSWORD_DEFAULT 就够用，它当前指向 bcrypt，未来 PHP 升级可能切到 Argon2，但老哈希仍能被新版本验证。除非你明确知道环境限制（比如某些旧容器没装 libargon2），否则别硬写死 PASSWORD_BCRYPT 或 PASSWORD_ARGON2ID。
立即学习“PHP免费学习笔记（深入）”；
可选的 $options 数组里，最常调的是 cost：
-
cost => 10到12是合理区间；值每 +1，计算耗时约翻倍 - 设太高（如 16）会导致登录延迟明显，尤其高并发时可能拖垮 Web 服务
- 设太低（如 8）会让暴力破解成本大幅下降，失去 bcrypt 意义
- 不需要传
salt参数 —— 函数内部自动生成并嵌入输出字符串，手动传反而会触发弃用警告
数据库字段要怎么设计
password_hash() 输出的字符串长度不固定，但当前 bcrypt 最长约 60 字符，Argon2 可达 255 字符。若字段类型是 VARCHAR(32) 或 CHAR(32)，插入会截断，导致后续 password_verify() 必然失败。
实操建议：
- MySQL 中设为
VARCHAR(255)，足够容纳所有当前及可预见的未来算法输出 - 别用
TEXT—— 虽然能存，但索引效率低，且无必要 - 字段名就叫
password_hash，别叫password或pwd，避免语义混淆 - 插入前不用额外过滤或转义 —— 哈希字符串只含 ASCII 可打印字符，不会触发 SQL 注入
password_verify() 验证时容易忽略的点
它不依赖外部 salt 或算法配置，只靠哈希字符串自身携带的元信息工作。但有几点必须注意：
- 第二个参数必须是完整原始哈希字符串（例如
$2y$10$...），不能是截断的、trim() 过的、或从 JSON 中 decode 出来时被意外转义的 - 如果数据库字段被定义为
CHAR且长度大于实际内容，MySQL 可能自动补空格 ——password_verify()会因末尾空格校验失败，查出来后记得rtrim() - 不要在验证前对用户输入做任何哈希（比如先
md5()再传给password_verify()）—— 它只接受明文密码 - 验证失败时，统一返回“用户名或密码错误”，别暴露“密码错”还是“用户不存在”，防止用户名枚举
真正麻烦的从来不是函数怎么调，而是旧系统里那些 md5($pass.$salt) 的遗留逻辑、字段长度卡死的表结构、以及开发时顺手写的 echo $hash 调试语句 —— 它们比算法本身更难清理干净。
