Laravel多guards是应对多身份业务的必需配置，非可选功能；需在config/auth.php中严格一一对应定义guards与providers，确保driver、model、provider键值精准匹配，避免session冲突、模型误查等硬伤。

直接说结论：Laravel 的多 guards 不是“可选功能”，而是应对真实业务分层的必需配置；只要你的应用存在 ≥2 种用户身份（比如前台用户、后台管理员、API 客户端、商户），就必须拆开定义独立的 guard 和 provider，否则会踩 session 冲突、模型误查、token 混用等硬伤。

怎么在 config/auth.php 里正确定义多个 guards

核心是两步：先配 guards，再配对应的 providers，二者必须一一对应，且 provider 名要和 guard 里的 provider 键值完全一致。

• guards 中每个守卫必须指定 driver（如 session、sanctum、http-basic）和 provider（字符串名，不写模型路径）
• providers 中每个提供者必须指定 driver（通常为 eloquent）和 model（完整类名，如 App\Models\Admin）
• 别把 api 守卫的 provider 指向 users，却让 admin 守卫也指向 users——这会导致管理员登录后 Auth::guard('admin')->user() 返回普通用户实例
• 如果你用 sanctum 做 API 认证，它默认只认 users 提供者；要支持多模型，必须额外配一个 sanctum_admin 守卫并绑定 admins 提供者

为什么 Auth::guard('xxx')->attempt() 有时返回 true 却拿不到用户

这不是代码 bug，而是守卫和提供者没对齐的典型表现。常见于以下情况：

Laravel Creem Agent

Creem 支付商店助理 — 查询订阅、客户、交易、产品，执行心跳检查，管理本地 Laravel支付商店。

下载

• 调用 Auth::guard('admin')->attempt($credentials) 后，Auth::guard('admin')->user() 为 null：检查 admin guard 的 provider 是否指向了正确的 Admin 模型，且该模型的 $fillable 包含 email 和 password
• 认证成功但 session 里存的是 User 模型：确认 admin provider 的 model 是 App\Models\Admin::class，不是 App\Models\User::class
• 使用 remember 参数后仍无法保持登录：session 驱动的守卫依赖 Laravel 的 session 存储机制，确保 SESSION_DRIVER 环境变量已设（如 redis 或 database），且中间件顺序中 StartSession 在 Authenticate 之前

路由中 auth:web,admin 是“或”还是“与”逻辑

逗号分隔的多个守卫名（如 auth:web,admin）是明确的“或”逻辑：Laravel 会按顺序尝试每个守卫，只要其中一个成功，请求就放行。

• 它不是同时校验两个守卫，也不是合并权限——只是短路式尝试
• 这个特性常用于开放接口：允许用户用 cookie 登录（web），也允许管理员用 token 直接访问（admin）
• 注意：如果两个守卫都用了 session 驱动，且共享同一个 session key（如都用 login_web_59ba36ab...），会出现互相覆盖；务必为不同守卫设置独立的 session 配置项（如 session → store 或自定义 id）
• 不要在同一个路由上混用 session 和 sanctum 守卫却不处理跨域或 CSRF，否则前端带 Cookie 请求可能被 sanctum 拒绝，而 sanctum token 又被 session 守卫忽略

动态切换 guard 时最容易漏掉的校验点

用 Auth::guard($request->guard)->attempt(...) 实现统一登录接口时，最危险的不是逻辑，而是边界失控。

• 必须用 in: 规则白名单限制 guard 参数值，禁止传入未定义的守卫名（如 guard=foo 会导致 Auth::guard('foo') 返回 null，后续调用 attempt() 报 Call to a member function attempt() on null）
• 不同守卫的密码加密方式可能不同（User 用 bcrypt，Admin 用 argon2），但 attempt() 不会自动适配——确保所有模型都用相同哈希算法，或在登录前手动比对
• 若某守卫用 token 驱动（如旧版 api），attempt() 成功后不会自动创建 token，需显式调用 $user->createToken(...)；而 sanctum 守卫的 attempt() 本身不生成 token，得靠后续 $user->createToken()
• 别在控制器里硬编码 Auth::guard('admin') 多次——抽成私有方法或 service，并把 guard 名作为参数注入，方便测试和 mock

多守卫真正的复杂点不在配置，而在状态隔离：session、cookie、token、CSRF token、remember me cookie，这些全都绑定在守卫名上。一旦命名或驱动错位，问题会延迟暴露——比如登录成功但登出失败，或用户能进后台却看不到自己的头像。动手前，先画一张 guard ↔ provider ↔ model ↔ driver 的映射表，比写十行代码更管用。