应重写用户模型的getAuthIdentifierName()方法返回登录字段名（如'email'），确保Auth::attempt()参数键名与之完全一致，并为该字段添加唯一索引；多guard需检查config/auth.php中provider配置是否指向修改后的模型。
修改 Authenticatable 的 getAuthIdentifierName()
默认 Laravel 用 id 字段做主键匹配，但登录时想用 email、username 甚至 phone 当“用户名”，核心不在登录表单或控制器，而在用户模型是否告诉框架“哪个字段才是我用来查用户的唯一标识”。
在你的用户模型（通常是 App\Models\User）里重写这个方法：
public function getAuthIdentifierName()
{
return 'email';
}
这样 Auth::attempt() 就会去查 email 字段，而不是硬编码的 id。注意：这只是告诉框架“用哪个字段查用户”，不改变密码校验逻辑，也不影响 Auth::user() 返回的对象结构。
- 必须返回数据库中真实存在的字段名，拼错会查不到用户，静默失败
- 该字段必须有唯一索引，否则并发登录可能出问题
- 如果用
username，确保迁移里加了$table->unique('username');
Auth::attempt() 传参要对得上字段
改了 getAuthIdentifierName() 后，Auth::attempt() 的第一个参数数组里，键名必须和它返回的字段一致。比如你设了 return 'email'，那就得传 ['email' => $request->email, 'password' => $request->password]。
常见错误是表单字段叫 username，但模型里写了 return 'email'，又没在控制器里做映射，结果永远 attempt() 失败。
- 检查登录请求的 key 是否和
getAuthIdentifierName()返回值完全一致（大小写敏感） - 如果前端传的是
username，后端可以手动映射：Auth::attempt(['email' => User::where('username', $request->username)->value('email'), 'password' => $request->password])，但更推荐统一字段名 - Laravel 10+ 默认登录验证器已移除对
username的硬依赖，别再翻旧文档找username()方法
自定义 Guard 时别漏掉 provider 配置
如果你用了多 guard（比如 admin 和 web），并在 config/auth.php 里配了自定义 provider，记得确认它的 model 指向的是你改过 getAuthIdentifierName() 的那个模型。
否则 guard 会加载默认 User 模型，你的重写根本不会生效。
- 检查
config/auth.php中对应 guard 的'provider' => 'users'，再看'users'provider 的'model'配置是否正确 - 运行
php artisan config:clear，避免缓存旧配置 - 用
dd(Auth::guard('your-guard')->getProvider()->createModel())在路由里临时验证模型实例是否是你预期的那个
密码重置和邮箱验证不受此影响
getAuthIdentifierName() 只控制“谁来登录”，不影响“怎么找回密码”或“怎么验证邮箱”。密码重置依然靠 email 字段发链接，邮箱验证也默认查 email 字段——哪怕你把登录字段改成 phone，只要 email 还存在且可写，这些功能照常工作。
真正容易被忽略的是：如果你禁用了 email 字段（比如全站用手机号登录注册），那 ForgotPassword 相关逻辑就得重写，Laravel 原生不支持用 phone 发短信验证码重置密码。
- 别假设改了登录字段就自动适配所有认证流程
- 邮箱验证中间件（
EnsureEmailIsVerified）仍检查email_verified_at，和登录字段无关 - 第三方登录（Socialite）通常走自己的 user resolver，不经过
getAuthIdentifierName()
