hash::needsrehash() 总返回 false 的根本原因是 laravel 版本低于 8.17，该方法在旧版本中恒返回 false；此外，若数据库 password 字段长度不足（如未设为 varchar(255)），新哈希被截断也会导致判断失效。
Hash::needsRehash() 是唯一可靠的密码升级触发器，但它只在用户下次登录时生效；不主动调用、不配合 save()，旧哈希永远不会变。
为什么 Hash::needsRehash() 有时总返回 false
常见错误现象：Hash::needsRehash($user->password) 在 Laravel false，哪怕你已把 config/hashing.php 里的 rounds 从 10 改成 12。
根本原因：Laravel 8.17 才开始在 needsRehash() 中真正读取当前配置的 cost / memory / time 参数，并与哈希串中嵌入的元信息比对。旧版本该方法只是个空壳。
使用场景：升级到 Laravel 11 后，默认 driver 已倾向 argon2id，但存量用户仍是 $2y$ 开头的 bcrypt——这时 needsRehash() 就成了算法迁移的守门人。
- 确认 Laravel 版本 ≥ 8.17（推荐 ≥ 10.0）
- 确保
php -i | grep -i argon显示支持，否则argon2id配置无效 - 别在迁移脚本里批量调用
needsRehash()然后直接重哈希——这会绕过用户验证环节，属于越权操作
登录流程中怎么安全插入 rehash 逻辑
错误写法：if (Hash::check(...)) { $user->password = Hash::make(...); $user->save(); } —— 这会在每次登录都强制重哈希，浪费 CPU，且破坏“仅当强度不足才升级”的语义。
正确做法是先验证，再判断是否需升级，最后仅更新：
if (Hash::check($request->password, $user->password)) {
if (Hash::needsRehash($user->password)) {
$user->password = Hash::make($request->password);
$user->save();
}
// 继续登录成功流程
}
关键点：
- 必须放在
Hash::check()成功之后，避免对错误密码也触发重哈希 - 不能在模型 mutator 或 observer 中做这件事——
$user->save()可能被多次调用，导致重复哈希 - 数据库字段必须是
VARCHAR(255)，否则新生成的$argon2id$哈希（最长约 250 字符）会被截断
升级 cost 或 memory 后性能掉得厉害怎么办
现象：把 bcrypt rounds 从 12 升到 14，单次 Hash::make() 耗时从 ~120ms 跳到 ~450ms，登录接口平均响应超 800ms，QPS 掉一半。
这不是配置错了，而是慢哈希设计本意——它本就要消耗资源来拖慢攻击者。但生产环境得平衡安全与体验：
- 先压测：用
ab -n 100 -c 10模拟并发登录，观察 CPU 和内存峰值 - Argon2id 的
memory别设超过 65536（64MB），否则高并发下容易 OOM - 如果服务器资源紧张，可暂时保持
rounds=12，但务必确保needsRehash()逻辑已就位，等后续扩容再升 - 注意：Laravel 11 默认仍用 bcrypt，不是自动切 Argon2id；要切，得手动改
config/hashing.php并确认 PHP 支持
历史密码表也要 rehash 吗
不用，也不该。
历史密码表（如 password_history）里存的是过去某次 Hash::make() 的结果，它和当前用户的主密码哈希一样，都受 needsRehash() 约束。但业务逻辑上，你只应在用户修改密码时写入一条新记录，而不是回溯重哈希所有旧记录。
容易被忽略的一点：如果你在密码修改逻辑里漏掉了对历史密码的 Hash::make() 调用（比如直接把明文塞进 password_hash()），那这条历史记录就脱离了框架哈希管理，未来即使主密码升级了，它也无法被 needsRehash() 识别。
所以重点不是“升级历史”，而是“确保每次写入历史都走 Hash::make()”。
