password_hash() 每次结果不同是因为默认使用 bcrypt 并自动随机生成盐，验证必须用 password_verify() 而非字符串比较；cost 默认 10，建议生产环境测压后设为 12 左右；迁移老密码需懒迁移，不可批量转换。
password_hash() 生成的哈希为什么每次都不一样
因为 password_hash() 默认使用 bcrypt 算法，并自动随机生成盐（salt）。这不是 bug，是设计——每次调用都会生成新盐，所以即使同一密码，输出也不同。
常见错误现象：password_verify() 返回 false，只因有人拿 password_hash() 的输出去比对字符串（比如存进数据库后又拿它和另一个 password_hash() 结果硬比较）。
- 永远不要用
==或===比较两个password_hash()结果 - 验证必须用
password_verify($plain_password, $hash_from_db) - 盐已完整内嵌在哈希字符串里（如
$2y$10$...开头的字符串），无需单独存或传
该不该指定 cost 参数？默认值够不够用
cost 控制 bcrypt 迭代轮数，默认是 10（PHP 7.0+），对应约 2^10 = 1024 次加密循环。太低不安全，太高拖慢登录响应。
使用场景：高并发登录接口、老旧服务器、容器化部署（CPU 资源受限）需谨慎调高。
- 生产环境建议测压后定值：用
password_hash('test', PASSWORD_BCRYPT, ['cost' => 12])测单次耗时，控制在 50–150ms 较稳妥 - 低于 10（如 8）易被暴力破解；高于 14 在普通 PHP-FPM 场景下可能让登录请求排队
- 别写死在代码里，建议配置化，比如从
$_ENV['HASH_COST']读取
password_hash() 不支持 MD5/SHA1，别硬套旧逻辑
有人想“升级”老系统，把数据库里存的 md5($pass) 直接喂给 password_hash()，结果发现验证永远失败——这是混淆了「加盐哈希」和「纯摘要」。
错误做法：password_hash($old_md5_hash, PASSWORD_DEFAULT)，这等于给一段哈希再哈希，完全脱离原始密码。
- 迁移老密码只能靠「懒迁移」：用户下次登录时，用原逻辑校验成功后，立刻用
password_hash()重哈希并更新数据库 - 绝不能批量转换，因为没明文密码，无法生成合规 bcrypt 哈希
- 如果老系统用了带盐的自定义逻辑（比如
md5($pass.$salt)），也没法反推，仍得等用户登录才可升级
验证时 password_verify() 失败的三个真实原因
不是函数有问题，通常是数据或流程断点。最常被忽略的是编码和截断问题。
- 数据库字段太短：
password_hash()输出最长约 60 字符（bcrypt），但有人用VARCHAR(32)存，导致自动截断，验证必败 - 密码含 UTF-8 特殊字符（如 emoji），而数据库连接或字段未设
utf8mb4，造成存储损坏 - 前端 JS 提交前 trim() 或 toLowerCase() 了密码，后端却拿原样去验证——前后不一致
复杂点在于：这些错误不会报异常，只会静默返回 false。查的时候得挨个核对输入、存储、取出三个环节的原始字节流，别只看“长得像”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
