直接在phpMyAdmin更新password字段不行，因为Laravel要求该字段必须是Bcrypt哈希值（约60字符，形如$2y$...），而非明文或MD5等其他哈希；手动填写明文或错误哈希会导致Hash::check()验证失败，登录报“These credentials do not match our records”。
phpMyAdmin 里直接更新 password 字段为什么不行
因为 laravel 的 password 字段必须是 bcrypt 哈希值，不是明文或其它哈希（如 md5、sha256）。直接在 phpmyadmin 里填入明文密码，比如 123456，用户登录时会失败——laravel 用 hash::check() 验证时会比对 bcrypt 哈希，而明文显然不匹配。
常见错误现象：
– 用户登录报 These credentials do not match our records.
– 查看数据库发现 password 字段是纯文本或长度固定（如 32 位），而非 60 字符左右的 Bcrypt 字符串（形如 $2y$10$...）
- 不要手动拼接 Bcrypt 字符串；Bcrypt 依赖 salt 和 cost factor，手写极易出错
- phpMyAdmin 不内置 Bcrypt 函数，
MD5()或SHA2()等 MySQL 内置函数完全无效 - 如果项目启用了
bcrypt的变种（如argon2id），更不能混用——得先确认config/hashing.php中的driver
用 Laravel Tinker 生成合法 Bcrypt 密码最稳妥
这是推荐做法：绕过 UI，用 Laravel 自身的哈希机制生成值，确保与运行时完全一致。
操作步骤：
- 进入项目根目录，执行
php artisan tinker - 输入
echo Hash::make('your_new_password');（注意单引号包裹明文） - 复制输出的完整字符串（以
$2y$或$2b$开头，共约 60 字符） - 回到 phpMyAdmin，找到
users表 → 编辑对应行 → 把password字段粘贴为该字符串 → 执行保存
为什么可靠？
– Hash::make() 自动读取 config/hashing.php 配置（如 rounds），和登录验证逻辑完全同步
– 不依赖 MySQL 版本或服务器环境
– 支持 Laravel 5.8+ 的默认 driver 切换（比如从 bcrypt 换成 argon2id）
立即学习“PHP免费学习笔记（深入）”；
不想开终端？用一小段 PHP 脚本临时生成
如果无法访问命令行（如共享主机），可上传一个临时脚本，用浏览器访问它来获取哈希值。
新建文件 hashgen.php，内容如下：
#!/usr/bin/env php <?php require __DIR__.'/vendor/autoload.php'; use Illuminate\Hashing\BcryptHasher; $hasher = new BcryptHasher(); echo $hasher->make($argv[1] ?? 'secret'); ?>
然后在终端运行：php hashgen.php mypass123；或通过 Web 访问（需确保 autoload.php 路径正确，且不暴露在生产环境）。
- 别把
hashgen.php留在生产服务器上，用完立刻删 - 如果项目用了自定义
HashManager（例如重写了createBcryptDriver），优先走app('hash')而非直接 newBcryptHasher - Web 方式调用时，避免 GET 参数传密码（会进 access log），改用 POST 或 CLI 更安全
更新后仍登录失败？重点检查这三处
生成和写入都对了，但还是登不进去，大概率是其他环节干扰了验证流程。
- 确认修改的是正确的
users表 —— 多租户或自定义认证模型时，可能实际用的是admins、members等表 - 检查用户记录的
email或username是否被误改，导致查不到该记录（Laravel 默认按email查，不是 ID） - 查看
config/auth.php中'provider' => 'users'对应的model和table配置是否匹配当前表结构
真正麻烦的点往往不在哈希本身，而在“你以为在改 A 表，其实登录走的是 B 表”，或者字段名被重命名为 passwd、pwd 却没同步改配置。动手前，先 dd(Auth::getProvider()->getModel()) 确认模型类，比反复试密码更省时间。
