PHP password_verify() 在首次登录成功但后续失败，通常并非算法或数据库问题，而是因源文件编码混杂（如UTF-8 with BOM、ISO-8859-1等）导致password_hash()生成的哈希字符串在写入或读取时被静默破坏。
php `password_verify()` 在首次登录成功但后续失败，通常并非算法或数据库问题，而是因源文件编码混杂（如utf-8 with bom、iso-8859-1等）导致`password_hash()`生成的哈希字符串在写入或读取时被静默破坏。
该问题本质是非功能性数据污染：password_hash() 生成的哈希字符串（例如 $2y$10$...）虽为ASCII字符，但若PHP文件本身以含BOM的UTF-8、Windows-1252或其他非纯UTF-8无BOM格式保存，当PHP解析器加载脚本时，可能在输出缓冲、字符串拼接或PDO参数绑定过程中引入不可见字符（如U+FEFF BOM头、多余换行或乱码字节），进而污染哈希值——尤其在UPDATE语句执行前，若哈希变量被意外拼接、日志打印或经由非安全函数处理，极易发生截断或尾部填充。
尽管你的数据库字段已设为 VARCHAR(255) 并使用 utf8mb4_unicode_ci，且能“肉眼比对”哈希一致，但关键陷阱在于：哈希值的完整性必须在二进制层面100%保真。任何额外字节（哪怕一个BOM或空格）都会使 password_verify() 返回 false，而这种差异在var_dump()或echo中往往不可见。
✅ 正确排查与修复步骤：
-
统一文件编码为 UTF-8 without BOM
使用命令行递归清理（Linux/macOS）：# 查找并转换所有 .php 文件（推荐先备份） find /var/www/your-project -name "*.php" -exec iconv -f UTF-8 -t UTF-8//IGNORE {} -o {}.fixed \; find /var/www/your-project -name "*.php.fixed" -exec mv {} {}.tmp \; find /var/www/your-project -name "*.php.tmp" -exec mv {} \;或更安全地使用 dos2unix + sed 清除BOM：
立即学习“PHP免费学习笔记（深入）”；
find /var/www/your-project -name "*.php" -exec dos2unix {} \; find /var/www/your-project -name "*.php" -exec sed -i '1s/^\xEF\xBB\xBF//' {} \; -
验证哈希写入过程无干扰
在 firstLoginUpdatePassword() 中添加调试校验（上线前移除）：error_log("HASH LENGTH: " . strlen($newPassword), 3, "/var/log/php-hash.log"); error_log("HASH RAW: '" . $newPassword . "'", 3, "/var/log/php-hash.log"); // 确保无前置/后置空白 $newPassword = trim($newPassword); -
强化数据库写入安全性
显式指定PDO参数类型，避免隐式转换：$stmt->bindValue(":password", $newPassword, PDO::PARAM_STR);
⚠️ 注意事项：
- 不要使用 mb_convert_encoding() 或 iconv() 对哈希字符串做任何编码转换——哈希是二进制安全的ASCII字符串，仅需原样存储；
- PHP 8 并非主因，但其更严格的字符串处理会放大编码问题的影响；
- 即使 SELECT 返回值看起来相同，也请用 bindec(str_split(bin2hex($hash), 2)) 比较十六进制字节流，而非直接 ===；
- 始终在生产环境禁用 error_log() 调试，改用结构化日志（如 Monolog）。
总结：密码哈希验证失败的“幽灵故障”，90%以上源于开发环境与部署环境的文件编码不一致。坚持“所有PHP文件→UTF-8无BOM→Git提交前校验”的规范，可彻底规避此类问题。
