PHP7.2 使用 password_hash 生成密码哈希，版本迁移后校验失败怎么排查-php教程-PHP中文网

password_verify()验证失败主因是哈希值被污染或截断，最常见为php文件含bom或编码混杂导致不可见字符混入；须用hex()和bin2hex()比对二进制一致性，而非肉眼查看。

php7.2 使用 password_hash 生成密码哈希，版本迁移后校验失败怎么排查

直接结论：不是 password_hash 本身不兼容，而是哈希值在生成、存储或读取环节被污染了——最常见的是 PHP 源文件含 BOM 或编码混杂，导致哈希字符串开头/结尾多出不可见字符。

别只看长度或肉眼比对，要验证二进制一致性：

用 SELECT HEX(password_hash) FROM users WHERE id = 1 查十六进制值，对比 PHP 中 bin2hex($hash) 输出是否完全一致
如果数据库里是 $2y$10$... 开头但长度不是 60，大概率被截断（如字段设成 VARCHAR(60) 而非 255）
旧项目若混用过 md5($pass.$salt)，哈希是 32 位纯小写十六进制，和 password_hash() 的 60 位 bcrypt 格式根本不同源，不能直接用 password_verify()

这是 PHP 7.2+ 迁移后最隐蔽也最高发的问题：

将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献

下载

用 file -i your_auth_file.php（Linux/macOS）或 VS Code 底部状态栏检查真实编码，必须是 utf-8 且显示 “without BOM”
Windows 记事本保存的文件极大概率带 BOM，改用 VS Code / Sublime Text 重新另存为 UTF-8 无 BOM
在哈希生成后立刻加一句：var_dump(strlen($hash), bin2hex($hash));，对比刚插入数据库前后的值——若长度变化或 hex 出现 efbbbf（BOM）就坐实了

ThinkPHP 5.0.x 等老框架默认用 think_ucenter_md5 或自定义 salt 拼接，和 password_hash() 无任何关系：

登录时不能只跑一遍 password_verify()，得先尝试旧逻辑（比如 md5($pwd.$salt)），失败再 fallback 到 password_verify()
验证通过后，若发现是旧格式，立刻用 password_hash($pwd, PASSWORD_BCRYPT, ['cost' => 12]) 重写密码字段——注意显式指定 PASSWORD_BCRYPT，避免 PHP 7.4+ 后 PASSWORD_DEFAULT 切到 argon2id
不要在迁移前批量“升级”所有密码哈希，会破坏旧用户登录流程；让升级自然发生在每次成功登录时

PHP 7.2 升级后报错常是环境断层，不是哈希函数本身问题：

执行 php -m | grep -i 'mbstring\|openssl'，确保 mbstring 和 openssl 已启用——password_hash() 依赖它们做随机盐生成
检查 php.ini 中 mbstring.func_overload 是否开启（已废弃），它可能静默改变字符串函数行为，污染哈希输出
若用 PDO 写入哈希，确认没有开启 PDO::ATTR_EMULATE_PREPARES，否则某些 MySQL 驱动会在绑定参数时做意外截断

真正难排查的永远不是算法差异，而是那些看不见的字符——BOM、空格、换行、零宽空格。只要哈希值在任意一环被改了一个字节，password_verify() 就会安静地返回 false，连 warning 都不给。