LaravelAPI如何实现登录_Laravel登录接口与Token返回【教程】

用 Sanctum 实现登录接口最轻量，核心是查用户→校验密码→发 token；Auth::attempt() 不适用 API 场景，因其仅返回布尔值且依赖 session，需改用 Hash::check() 显式验证，再调用 $user->createToken() 返回 plainTextToken。

在 Lara vel 中构建 API 登录接口，Sanctum 通常是那个最轻量、最贴合场景的选择。它直接返回 token 的流程非常清晰。至于 Passport，除非你的项目确实需要完整的 OAuth2 流程，否则完全可以先放一边。

为什么不用 Auth::attempt() 直接返回 token

很多开发者踩的第一个坑，就是用了 Auth::attempt() 之后发现无从下手——它只返回一个布尔值，根本不生成 token。这其实不怪它，因为 Lara vel 传统的认证系统是为 Web 表单登录设计的，依赖 session 和 cookie。这套机制和纯 API 场景下使用的 Authorization: Bearer 头，从根子上就是两码事。

• 关键点在于，Auth::attempt() 成功后，并不会自动创建 API token，也不会返回任何能给前端直接使用的凭证。
• 如果你想手动调用 $user->createToken()，必须确保用户已经通过了认证。否则，岂不是给任意邮箱密码组合都能创建 token？
• 如果跳过密码校验直接去 createToken，那就等于完全绕过了安全验证，会留下严重的安全漏洞。

Sanctum 登录接口怎么写才不踩坑

核心逻辑说起来就三步：查用户、校验密码、发放 token。但这里的顺序和异常处理，直接决定了接口能否抵御重放攻击或密码爆破。

• 第一步，先用 User::where('email', $request->email)->first() 把用户查出来。这里不建议用 Auth::attempt() 包裹整个流程，因为它在失败时会触发 Lara vel 默认的“登录失败锁定”机制，这对 API 来说并不友好。
• 用户存在？好，接下来用 Hash::check($request->password, $user->password) 进行显式的密码比对。如果失败，直接返回 401 Unauthorized 响应。
• 密码也对了，这时候才调用 $user->createToken('api-token')。注意，返回给前端的是 $token->plainTextToken，而不是 $token->token 这个哈希值。
• 还有一个小细节：务必检查 config/auth.php 里 guards.api 的 driver 是否设置为 sanctum。否则，后续的认证中间件可能会静默失败，让你排查半天。

POST /login 接口的请求体和响应要严格对齐

接口契约必须清晰。前端传过来的字段名、后端返回的状态码和响应结构，错一个都可能让调用方反复抓包调试。

• 接收字段最好固定为 email 和 password。别自己发明 username 或 passwd —— Sanctum 可不会帮你做字段映射。
• 成功响应状态码用 200，响应体里必须包含 token 字段，格式一目了然：

  {"token": "1|abc..."}

• 失败一律返回 401。这里要区分清楚：422 通常用于表单验证错误，而密码错误是认证失败，不是服务器内部错误，所以也别用 500。
• 响应里不需要塞入完整的 user 对象。token 本身不携带用户信息，后续请求通过 auth:sanctum 中间件来解析 token 并自动加载对应用户。

最后，还有一个容易忽略的实践细节：Sanctum 默认创建的 token 是永不过期的，注销需要手动调用 $user->tokens()->delete()。前端拿到 token 后，需要将其存入 localStorage 或内存变量中，不能依赖 cookie，否则在跨域请求时可能无法携带出去。