Sanctum 不能直接用 token 做 SPA 认证，因其 PersonalAccessToken 专为 API 设计，依赖 Authorization 头，而 SPA 跨域时无法安全存储和自动携带该头；Sanctum 对 SPA 实际采用基于 session 的认证机制，通过 CSRF cookie 和会话 Cookie（laravel_session）实现无状态外观。
Sanctum 为什么不能直接用 token 做 SPA 认证？
Sanctum 的 token（即 PersonalAccessToken）默认是为 API 场景设计的，它依赖请求头中的 Authorization: Bearer {token}。但典型 SPA（如 Vue/React 前端部署在独立域名或静态服务上）无法安全持久存储该 token 并自动注入每个请求——尤其跨域时浏览器不会自动携带 Authorization 头，且 localStorage 存 token 有 XSS 风险。
所以 Sanctum 对 SPA 的支持不是靠 token，而是靠「基于 session 的无状态外观」：它用 Laravel 的 session + CSRF 机制完成登录，后续请求靠 cookie 自动携带 session ID，服务端验证 session 而非 token。表面看“无状态”，实则状态保留在服务端 session 中，只是前端无需管理 token 生命周期。
如何让 SPA 正确发起登录并建立认证会话？
关键在于三点：跨域配置、CSRF 同步、登录接口调用方式。漏掉任一环节都会导致 419 或 401。
- 确保
config/cors.php允许前端域名，并开启'supports_credentials' => true - 前端首次请求必须先访问
/sanctum/csrf-cookie（GET），触发 Laravel 设置XSRF-TOKENcookie 和同名响应头 - 登录请求（如 POST
/login）需带上X-XSRF-TOKEN请求头，值取自上一步响应头中的XSRF-TOKEN - 登录接口本身不能用
auth:sanctum中间件——它还没登录，要用guest或无中间件
axios.get('/sanctum/csrf-cookie').then(() => {
return axios.post('/login', {
email: 'user@example.com',
password: 'secret'
}, {
headers: {
'X-XSRF-TOKEN': document.cookie.match(/XSRF-TOKEN=([^;]+)/)?.[1] || ''
}
});
});
auth:sanctum 中间件到底验证什么？
它不检查 token 字符串，而是调用 SanctumGuard::user()，该方法优先尝试从 session 中恢复用户（$this->guard->user()），失败后才 fallback 到 token 解析（仅当请求带 Authorization: Bearer 时）。对 SPA 来说，只要 session cookie（laravel_session）有效且未过期，就直接通过。
- session 过期时间由
config/session.php的lifetime控制，默认 120 分钟 - CSRF token 每次请求会刷新，但不影响 session 有效性
- 若前端清除了所有 cookie，或服务端 session 被 GC 清理，则下次请求会返回 401，需重新走 CSRF + 登录流程
为什么不能在 SPA 中手动创建并使用 PersonalAccessToken？
可以创建，但违背 Sanctum 对 SPA 的设计意图，且带来实际问题：
- 前端需自行存储 token（localStorage/sessionStorage），暴露于 XSS
- 每次请求都得手动加
Authorization: Bearer头，Axios/Fetch 默认不自动携带 - token 无法自动刷新，过期后用户需重新登录，而 session 可通过延长 lifetime 或活动续期更平滑
- Laravel 默认不会为 SPA 请求解析
PersonalAccessToken—— 它只在 API 场景下被EnsureFrontendRequestsAreStateful中间件排除，而 SPA 请求会被该中间件放行到 session 流程
如果硬要用 token，得显式在路由中移除 EnsureFrontendRequestsAreStateful，并自己处理 token 提取与验证逻辑，等于绕开 Sanctum 的 SPA 模式，得不偿失。