password_verify()验证失败主因是哈希值被污染或截断，最常见为PHP文件含BOM或编码混杂导致不可见字符混入；须用HEX()和bin2hex()比对二进制一致性，而非肉眼查看。
直接结论：不是 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 文件本身没带 BOM 或乱码
这是 PHP 7.2+ 迁移后最隐蔽也最高发的问题：
- 用
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() 无任何关系：
论文常用的tex格式转换为word格式，核心是能转换数学公式（非图片），表格，图表等等
下载
将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献
立即学习“PHP免费学习笔记（深入）”；
- 登录时不能只跑一遍
password_verify()，得先尝试旧逻辑（比如md5($pwd.$salt)），失败再 fallback 到password_verify() - 验证通过后，若发现是旧格式，立刻用
password_hash($pwd, PASSWORD_BCRYPT, ['cost' => 12])重写密码字段——注意显式指定PASSWORD_BCRYPT，避免 PHP 7.4+ 后PASSWORD_DEFAULT切到argon2id - 不要在迁移前批量“升级”所有密码哈希，会破坏旧用户登录流程；让升级自然发生在每次成功登录时
PHP 版本与扩展链是否断裂
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 都不给。
