Laravel 5.5 应使用 Passport 而非默认 api guard 或自定义 token guard，因其支持签名、过期、吊销及 scope 控制；必须在 AuthServiceProvider boot() 中调用 Passport::routes()，否则 OAuth 路由 404；前端需严格按 Bearer <token> 格式传参，PAT 不可用于 Web 前端。
Token 认证该用 api guard 还是自定义 token guard？
Laravel 5.5 默认的 api guard 使用的是 token 驱动，但它只支持单字段 token（如数据库里一个 api_token 字段），不校验过期、不绑定设备或 IP，也不自动刷新——这在真实 API 场景中等于裸奔。
真正安全的做法是弃用默认 token 驱动，改用 passport（官方推荐）或轻量替代方案 sanctum（但注意：Sanctum 是 Laravel 8+ 才内置，5.5 不可用）。所以 5.5 下唯一合规选择是 passport。
-
passport基于 OAuth2，生成带签名、可设过期、可 revoke 的 JWT-style token - 它自动处理
Authorization: Bearer <token>解析、中间件auth:api绑定、scopes 权限控制 - 不要手动用
Hash::make()存 token——密码哈希不可逆，而 token 必须可查库比对
Passport::routes() 必须注册在哪个位置？漏掉会怎样？
必须在 app/Providers/AuthServiceProvider.php 的 boot() 方法里调用 Passport::routes()，且要确保该 Provider 已在 config/app.php 的 providers 数组中启用。
漏掉的直接后果：访问 /oauth/token 返回 404；调用 Passport::personalAccessClient() 报错；所有 Passport 内置路由（发 token、刷新、revoke）全部失效。
- 别在
RouteServiceProvider里注册——Passport 路由依赖服务容器中的Passport实例，提前加载会报Call to a member function routes() on null - 如果用了多域名或子域，需额外调用
Passport::ignoreRoutesWhen()避免冲突 -
Passport::tokensCan()应在boot()中紧随routes()后设置 scopes，否则 scope 校验永远失败
前端传 Token 时常见错误：为什么总是 401 Unauthenticated？
绝大多数不是后端逻辑问题，而是请求头格式或 token 值本身出错。Laravel Passport 严格校验 Authorization 头格式为 Bearer <actual_token_string>，少空格、多空格、大小写错（比如 bearer 小写）、或 token 带前后引号都会失败。
- 检查浏览器 DevTools → Network → Headers → Authorization 是否为
Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6Ij...（无引号、首字母大写、中间一个空格） - Postman 里选 “Bearer Token” 类型，别手输整个字符串到 Key/Value 表单
- axios 默认不发送 credentials，但 token 认证无需
withCredentials: true；加了反而可能触发 CORS 预检失败 - token 过期后不能复用——
401不代表认证失败，很可能是token_expired，需前端捕获响应并跳转登录或静默刷新
如何安全地存储和使用 Personal Access Token？
Personal Access Token（PAT）适合 CLI 工具、调试或可信内部服务调用，**绝不能用于 Web 前端发起的用户请求**——因为 PAT 永不过期、无法 revoke 单个 token、且一旦泄露等于永久接管账号。
- 生成后立即存入安全环境变量或加密配置，不要硬编码在 JS 或 Blade 模板中
- 用
php artisan passport:client --personal创建，生成的id和secret只显示一次，丢失只能删库重来 - 数据库中
oauth_access_tokens表的expires_at字段对 PAT 是null，靠revoked字段控制生命周期 - 若必须前端用，至少用 short-lived JWT 替代 PAT，并配合 refresh token 流程——但这已超出 Passport 默认能力，需自行实现
真正麻烦的不是生成 token，而是 token 泄露后的快速响应机制：你得有 revoke 接口、审计日志、以及定期轮换 client secret 的运维流程。没这些，再“标准”的 OAuth2 也只是纸面安全。
