PHP 5.6 的 password_hash 在 PHP 7.0+ 验证失败主因是 ThinkPHP 5.0.x 使用 md5 或 think_hash，而新项目用原生 password_hash，两者格式不兼容；应通过 password_get_info 区分格式并双逻辑验证，旧密码成功后升级为 bcrypt 哈希，且显式指定 PASSWORD_BCRYPT 和 cost 参数以保证跨版本一致性和性能可控。
PHP 5.6 下 password_hash 生成的哈希在 PHP 7.0+ 验证失败？
不是算法本身不兼容，而是 ThinkPHP 旧版本（如 5.0.x）默认用 md5($password.$salt) 或自定义 think_hash，而新项目启用了 PHP 原生 password_hash（PASSWORD_DEFAULT），两者根本不同源。直接混用会始终返回 false。
实操建议：
- 确认当前数据库中密码字段存的是哪种格式：查几条记录看哈希长度——32 位是
md5，60 位大概率是password_hash（$2y$或$2i$开头） - 不要强行把旧密码“升级”成新哈希再入库；应让验证逻辑能识别两种格式并分别处理
- ThinkPHP 5.0 没有内置对
password_verify的封装，需手动补一层兼容判断
ThinkPHP 5.0 中如何安全支持新旧密码哈希共存？
核心思路是：登录时先尝试用原逻辑（如 think_ucenter_md5）比对，失败再用 password_verify 尝试。验证通过后，若发现是旧格式，顺手用 password_hash 重写密码到数据库（仅对本次用户生效）。
示例关键逻辑：
立即学习“PHP免费学习笔记（深入）”；
// $user['password'] 是数据库取出的哈希值
if (password_get_info($user['password'])['algo'] === 0) {
// 旧格式：可能是 md5('xxx'.$salt) 或 think_hash()
$legacyOk = $user['password'] === md5($password . $user['salt']);
} else {
// 新格式：直接走 PHP 原生验证
$legacyOk = password_verify($password, $user['password']);
}
if ($legacyOk && password_get_info($user['password'])['algo'] === 0) {
// 是旧格式且验证成功 → 升级哈希
$newHash = password_hash($password, PASSWORD_DEFAULT);
Db::name('user')->where('id', $user['id'])->update(['password' => $newHash]);
}
PASSWORD_DEFAULT 在 PHP 5.6 和 7.4 下行为差异有多大？
PHP 5.6 的 PASSWORD_DEFAULT 实际指向 PASSWORD_BCRYPT（$2y$），但部分编译版本可能因 OpenSSL 版本缺失而 fallback 到 crypt()，导致哈希不可移植；PHP 7.4+ 则稳定使用 $2y$，且默认 cost=10。
容易踩的坑：
- 在 PHP 5.6 环境下用
password_hash($pwd, PASSWORD_DEFAULT)生成的哈希，某些低配 CentOS 6 机器无法被 PHP 7.2+ 正确识别——不是算法问题，是$2y$被误解析为$2a$导致校验失败 - 避免依赖
PASSWORD_DEFAULT做跨版本迁移；统一显式指定PASSWORD_BCRYPT并固定['cost' => 10] - ThinkPHP 自带的
think_encrypt和密码哈希无关，别混淆——它只用于数据加解密，不是密码存储方案
升级后登录变慢、CPU 占用飙升？检查 password_hash 的 cost 参数
password_hash 默认 cost=10，意味着约 2^10 次迭代，在老旧服务器上单次验证可能耗时 100ms+。如果用户频繁输错密码，或并发登录量大，很容易触发 CPU 尖峰。
优化建议：
- 上线前用
password_hash('test', PASSWORD_BCRYPT, ['cost' => 10])实测单次耗时，超过 50ms 就该调低（如cost => 8） - 不要在 CLI 环境（如队列任务）里调用
password_verify——它不是为高吞吐设计的，验证逻辑必须限定在 Web 请求入口 - 数据库索引对哈希字段无效，别指望加索引加速登录；重点压测验证函数本身
真正麻烦的从来不是怎么写通，而是旧数据格式杂、PHP 版本碎片化、以及 cost 参数在不同机器上实际耗时不一致——这些细节不测到线上环境，根本没法预估影响范围。
