laravel密码重置常见问题包括：token明文与哈希校验不一致、重置链接缺token/email参数、邮件异常被静默处理、多guard下broker未正确配置、url签名验证干扰自定义流程，需统一token生成验证逻辑并显式指定guard与broker。
密码重置链接 404 或 token 失效
Laravel 默认的 ResetPasswordController 依赖数据库中 password_resets 表的 token 字段做校验，但 token 实际是哈希值（用 Hash::make() 生成），而 URL 中传递的是明文 token —— 这意味着你必须确保路由、中间件和验证逻辑全程使用同一套解析方式。
常见错误是手动拼接重置链接时漏掉 token 参数，或在自定义邮件模板里用了 $request->token（实际应为 $resetToken 或 $user->token，取决于你重写的逻辑）；更隐蔽的问题是：如果你覆盖了 reset 方法但没调用 Auth::guard()->validateCredentials() 前的 canResetPassword() 检查，token 过期后仍会进入表单页，只是提交时报 Invalid password reset token.。
- 检查
config/auth.php中passwords.users.expire是否设为 60（单位分钟），别误写成 60 秒 - 重置链接必须包含完整参数：
?token=xxx&email=yyy，缺一不可；email参数用于定位用户，不是可选的 - 若用自定义通知类，确保
toMail()方法里调用的是$notifiable->createToken()的返回值，而不是直接输出模型字段
邮箱发送失败但无报错提示
Laravel 密码重置流程默认静默处理邮件异常：即使 Mail::to()->send() 抛出 Swift_TransportException，ForgotPasswordController@sendResetLinkEmail 也只返回 200 并显示 “We have emailed your password reset link!”。用户收不到邮件，却以为已成功。
根本原因是 SendResetLinkEmail trait 中的 sendResetLinkResponse() 和 sendResetLinkFailedResponse() 都不抛出异常，且默认未开启 MAIL_FAIL_EXCEPTIONS=true。
- 开发环境务必在
.env加上MAIL_FAIL_EXCEPTIONS=true，否则无法捕获 SMTP 连接失败、认证拒绝等底层错误 - 不要依赖
Mail::fake()测试生产逻辑——它会吞掉所有异常，导致本地测试通过但线上挂掉 - 若用 API 方式触发重置（如 Vue + Laravel Sanctum），需手动 catch
Illuminate\Auth\Passwords\PasswordBroker::RESET_LINK_SENT以外的返回码，并透传错误信息
自定义密码重置逻辑绕过内置校验
很多人想跳过邮件流程，直接用手机号+短信验证码重置密码，这时容易直接复写 ResetPasswordController@reset 却忽略两个关键点：一是 $request->hasValidSignature() 会校验 URL 签名（Laravel 8+ 强制启用），二是 Auth::guard()->attempt() 不接受明文密码，必须先用 Hash::make()。
最常踩的坑是：在短信重置场景下仍保留 password_resets 表校验，导致用户填完新密码后提示 The password reset token is invalid.，其实 token 根本没被生成过。
- 若完全弃用邮件流程，删掉
ResetPasswordController对ResetsPasswordstrait 的 use，改用纯自定义方法 - URL 签名验证可通过
use Illuminate\Routing\Middleware\ValidateSignature;手动跳过，但更稳妥的是在路由定义时加->withoutMiddleware(ValidateSignature::class) - 更新密码必须调用
$user->forceFill(['password' => Hash::make($request->password)])->save()，不能直接赋值再 save，否则updating事件可能干扰哈希过程
多守卫（guard）下账户恢复失败
当项目有 web 和 api 两个 guard，且都启用了密码重置，ForgotPasswordController 默认只走 web guard，ResetPasswordController 同样不会自动识别请求来自哪个 guard —— 结果就是 API 用户点击重置链接后，页面跳转到 web 登录页，或 token 校验时查错表（比如 api_users 表没配 password_resets 关联）。
核心问题在于 Auth::guard() 默认返回 config('auth.defaults.guard')，而非根据当前请求上下文动态切换。
- 在控制器构造函数中显式指定守卫：
$this->guard = Auth::guard('api');，并重写broker()方法返回对应 broker 实例 -
passwords配置项必须为每个 guard 单独定义，例如'api' => ['provider' => 'api_users', 'table' => 'api_password_resets', 'expire' => 60] - 前端调用时，重置链接的
guard参数不会被自动识别，需在路由中显式传入，例如：Route::get('/reset-password/{token}', [ResetPasswordController::class, 'showResetForm'])->name('password.reset')->middleware('signed')->where('token', '.*');后续逻辑靠路由参数或 header 判断守卫类型
