SpringBoot+Vue整合Sa-Token实现无Cookie登录：从配置到实战全解析

最新推荐文章于 2026-07-05 11:23:18 发布

原创

最新推荐文章于 2026-07-05 11:23:18 发布 · 197 阅读

1. 为什么选择Sa-Token？聊聊前后端分离登录的那些“坑”

大家好，我是老陈，一个在前后端领域摸爬滚打了十多年的老码农。今天想和大家深入聊聊一个在前后端分离项目中，几乎每个开发者都会遇到的“老大难”问题：登录状态管理。

回想几年前，我们做传统Web项目，登录态基本靠Session和Cookie。浏览器自动带着Cookie，后端从Session里取用户信息，一切看起来顺理成章。但到了前后端分离的时代，尤其是Vue、React这些框架大行其道，前端独立部署，事情就变得复杂了。你可能会遇到：跨域请求时Cookie带不过去、APP或小程序根本不吃Cookie这一套、还有那个让人头疼的CSRF安全问题。更别提在微服务架构下，Session共享又是一座大山。

我试过不少方案，从自己手写JWT Token管理，到引入Spring Security进行深度定制，过程堪称“踩坑之旅”。手写JWT，密钥管理、刷新机制、注销黑名单都得自己来，代码越写越臃肿；用Spring Security，功能强大但学习曲线陡峭，配置复杂，想实现一个简单的无Cookie登录都得研究半天文档。

直到我遇到了Sa-Token。说实话，第一次用的时候有点惊讶，它把权限和会话管理做得如此轻巧。它不像一个沉重的框架，更像是一套精心设计的工具集。特别是它对“无Cookie模式”的原生支持，几乎是为前后端分离、移动端应用量身定做的。你不需要再纠结于Cookie的SameSite属性、跨域配置，也不用自己手动在请求头里拼接和解析Token。Sa-Token帮你把这些脏活累活都干了，你只需要关心最核心的业务逻辑：谁登录了，他能干什么。

所以，如果你正在用SpringBoot和Vue开发项目，被登录流程搞得焦头烂额，或者想寻找一个更优雅、更现代的权限认证方案，那么跟着我一起，把Sa-Token整合进你的项目，你会发现原来登录可以这么简单。接下来，我会从零开始，带你完成从框架配置、前后端代码编写到最终验证的完整流程，保证你看完就能上手。

2. 环境准备与Sa-Token基础配置

工欲善其事，必先利其器。在开始写代码之前，我们得先把项目和依赖准备好。这里我假设你已经有一个基础的SpringBoot 3.x项目和一个Vue 3项目。如果你的SpringBoot是2.x版本，也不用担心，依赖上稍有不同，我会特别说明。

2.1 引入核心依赖

首先，打开你的SpringBoot项目的pom.xml文件，添加Sa-Token的依赖。这是最关键的一步。

<!-- Sa-Token 权限认证框架，SpringBoot 3.x 专用 starter -->
<dependency>
    <groupId>cn.dev33</groupId>
    <artifactId>sa-token-spring-boot3-starter</artifactId>
    <version>1.41.0</version>
</dependency>

注意：版本号请以官方仓库（如Maven Central）的最新稳定版为准。我这里写的1.41.0是一个示例版本。

如果你不幸（或者说，你的老项目）还在使用SpringBoot 2.x，那么请使用下面这个依赖：

<!-- Sa-Token 权限认证框架，SpringBoot 2.x 专用 starter -->
<dependency>
    <groupId>cn.dev33</groupId>
    <artifactId>sa-token-spring-boot-starter</artifactId>
    <version>1.41.0</version>
</dependency>

看到没？Sa-Token的团队考虑得很周到，为不同主版本的SpringBoot提供了不同的Starter，避免了潜在的兼容性问题。引入依赖后，Maven会自动下载相关的jar包。这个核心包非常轻量，只有几百KB，不会给你的项目带来任何臃肿感。

2.2 配置文件详解：开启无Cookie模式

依赖加好了，接下来就是配置。Sa-Token的配置非常清晰，大部分采用默认值就能工作。但为了实现我们的“无Cookie登录态”，需要修改几个关键配置。

打开你的application.yml（或application.properties），我习惯用yml，结构更清晰。添加如下配置：

############## Sa-Token 配置 ##############
sa-token:
  # token 名称，也是我们后续要在请求头中携带的字段名
  token-name: satoken
  # token 有效期，单位秒，这里设置30天。 -1 代表永久有效（不推荐）
  timeout: 2592000
  # 是否允许同一账号多地同时登录。true为允许，false则新登录会挤掉旧登录
  is-concurrent: true
  # 在多人登录同一账号时，是否共用一个token。false表示每次登录都新建一个token，更安全
  is-share: false
  # token 风格，默认为 uuid。可选 simple-uuid、random-32、jwt 等，后续我们会集成JWT
  token-style: uuid
  # 是否输出框架内部的操作日志，开发阶段可以开启，便于调试
  is-log: true
  # ############ 关键配置：开启无Cookie模式 ############
  # 是否从 Cookie 中读取 Token，我们关闭它
  is-read-cookie: false
  # 是否从 Header 中读取 Token，我们开启它。这样Token就通过请求头传递了
  is-read-header: true

我来重点解释一下最后两个配置，这是实现无Cookie模式的核心：

is-read-cookie: false：告诉Sa-Token，别再去请求的Cookie里找名为satoken的东西了。这样，我们的认证就与浏览器Cookie彻底解耦。
is-read-header: true：告诉Sa-Token，请从HTTP请求头里读取Token。默认情况下，它会去读取请求头中名为token的字段（这个字段名可以通过token-name配置，我们上面配的是satoken）。这意味着，前端需要在每次请求时，在Header里加上satoken: xxxxx。

这样一来，整个认证的载体就从“浏览器自动管理的Cookie”变成了“由前端代码手动控制的请求头”。无论是Vue网页、React Native APP还是微信小程序，只要你能在发起网络请求时设置请求头，就能轻松接入这套登录体系，灵活性大大提升。