password_verify()在php 7.2及更低版本无行为差异，核心问题在于函数是否存在及哈希格式识别：php 5.4等旧版本若未加载password_compat则根本不存在该函数；验证时须先用function_exists()确认，再依password_get_info()判断算法类型分路处理，避免误fallback至不安全的md5。
password_verify() 在 PHP 7.2 和更低版本的行为差异
PHP 7.2 的 password_verify() 本身没有行为变更，真正出问题的是它依赖的底层哈希格式识别逻辑——尤其是当数据库里存了旧式 md5、sha1 或自定义 salt 拼接的哈希时。PHP 7.2 会严格按 $2y$、$argon2i$ 等前缀解析算法；而 PHP 5.4 或早期 7.x 若没加载 password_compat，调用 password_verify() 会直接报 Call to undefined function password_verify()，根本走不到“返回值不一致”这步。
先确认是不是真在调用 password_verify()
很多所谓“返回值不一致”，其实是误判：旧环境根本没这个函数，却写了调用代码，结果抛出致命错误而非返回 false。必须加兜底检查：
- 运行
var_dump(function_exists('password_verify'));，返回false就说明函数压根不存在，不是“返回值不同” - 若返回
true，再测password_verify('abc', '$2y$10$...')是否返回true/false—— 这才是真兼容性问题 - 常见误操作：在 PHP 5.4 环境下没引入
password_compat，却直接写password_verify()，导致 500 错误
旧哈希格式导致验证逻辑分支断裂
真正容易踩坑的是混合存储场景：数据库里既有 password_hash() 生成的 y$ 哈希，也有老系统遗留的 md5($pwd.$salt)。PHP 原生 password_verify() 对非标准前缀哈希一律返回 false，但旧逻辑可能还依赖 md5() 验证——这时不能只靠 password_verify() 一把梭。
将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献
- 必须用
password_get_info($stored_hash)['algo']判断哈希类型：0表示非标准（大概率是 MD5/SHA1），1表示 bcrypt - 不要写
if (password_verify(...)) { ... } else { md5(...) }—— 这会让所有 bcrypt 失败都 fallback 到 MD5，极大扩大攻击面 - 正确做法是先判断类型，再分路验证：
if ($info['algo'] === 0) { legacy_check(); } else { password_verify(); }
cost 参数或盐值异常引发的隐性失败
PHP 7.2+ 的 password_verify() 对 bcrypt 成本参数更敏感。如果旧系统用了 crypt($pwd, '$2a$12$...') 手动构造哈希，而 cost=12 在某些内核（如 glibc 2.12）上超时，PHP 可能静默返回 false 而不报错——看起来像“验证失败”，实则是底层 crypt() 调用失败。
- 检查哈希字符串是否以
$2y$开头（PHP 7.2+ 推荐），避免用$2a$或$2x$（已废弃且兼容性差） - 如果必须支持旧哈希，确保生成时
cost不超过10，尤其在 PHP 5.4–7.1 环境下 - 数据库字段必须是
VARCHAR(255)，60 字符哈希被截断后，password_verify()必然返回false
最常被忽略的一点：password_verify() 的返回值只有 true 或 false，它从不抛异常。所谓“不一致”，90% 是因为没做 function_exists() 检查，或混淆了哈希格式迁移阶段的双逻辑验证边界。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
