Java Web考勤系统源码：SpringBoot2+Vue3前后端分离全解析

我之前帮朋友整理过好几套高校相关的 Java Web 项目，发现一个规律：凡是带“考勤系统”字样的源码，十套里有八套的代码结构还停留在 JSP+Servlet 时代，能跑，但看着实在闹心。这套“Java Web 大学生考勤系统源码-SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0”是我近期拿到手并且完整跑通的一套，前后端分离，还带文档，技术栈正好踩在现在毕业设计和课程设计的主流点上。如果你正打算用这套源码做毕设，或者想找一份能练手的前后端分离项目，这篇文章可以帮你省掉几天的摸索时间。我会从业务设计、技术选型、数据库、后端接口、前端联调、部署文档几个角度拆开讲，最后再把跑通过程中最容易踩的坑单独列出来。

1. 考勤系统的业务边界：它要管的不是打个卡这么简单

很多人一听到“考勤系统”，第一反应就是“签个到”。如果只按签到来设计，做出来的东西就是一张表加两个接口，撑不起一个完整项目。这套源码在业务上做了一层比较完整的拆解：学生、教师、管理员三种角色，配合排课、签到、请假、统计四个主流程，才把“考勤”这个概念真正落了地。

1.1 三种角色的权限差异

学生端能看课程表、发起签到、提交请假、查自己的出勤记录；教师端能维护课程、发起签到任务、审批请假、看班级统计；管理员端负责用户、班级、课程的基础数据管理，还要维护系统参数配置。角色不同，前端能看到的菜单不同，后端接口也需要做权限校验。我见过很多源码只在页面上把按钮隐藏，接口却能直接访问，这种问题在答辩时基本都会被问倒。正确做法是后端用拦截器或注解统一鉴权，前端只负责展示隐藏。

权限这一层如果设计得清楚，后面扩展功能会非常舒服。比如要给辅导员开一个“查看全系出勤率”的页面，只需要新增一个角色和对应菜单，不用动签到主流程。反过来，如果一开始把角色写死在业务代码里，一个 if 套一个 if，后面每加一个角色都要改一圈逻辑，非常痛苦。这套源码的角色设计是把“角色”和“菜单”做成多对多关系，权限数据放数据库，代码里只留一个校验注解，算是比较标准的做法。

1.2 核心流程：排课、签到、请假、统计

考勤的核心链路不是“学生点一下按钮”就结束，而是从教师排课开始。教师在一门课程下关联多个班级，然后发起一次签到任务，签到的有效时间窗口、允许迟到的时间、过期时间都可以由教师配置。学生登录后看到当前可签到的课程，点击签到，后台记录状态。如果学生在签到窗口外提交申请，就会进入请假或补签流程，由教师审批。

统计模块的输入是签到记录和请假记录，输出是每个学生、每个班级、每门课程的出勤率、迟到率、缺勤率。这里有一个容易忽略的点：统计口径。比如“出勤率”的分母到底是应到次数还是已到次数？如果学生请假，算不算出勤？这套源码里把请假单作为独立状态处理，只要教师审批通过，该次记录就标记为“请假”，在统计时单独列一行，不计入缺勤，也不计入正常出勤。口径在文档里写得很清楚，这一点值得借鉴。

1.3 考勤规则不能写死，要可配置

我见过不少考勤项目，迟到几分钟算迟到是写死在 Controller 里的，每次改规则都要重新发版。这套系统的做法是把考勤规则放进一张系统配置表，比如“签到开始时间偏移量”“迟到判定时间”“缺勤判定时间”“每月补签次数上限”。教师发起签到时，页面默认读取全局配置，也可以针对某次课程临时覆盖。

配置化的好处很直接：学期变了、老师要求变了，管理员在后台改一下数字就行。对于答辩来说，这也是一个很好的加分点，可以讲“系统支持多维度考勤规则配置，具备可扩展性”。如果你自己跟着写一遍，建议把配置表设计成 key-value 结构，一个全局配置表就可以覆盖大部分场景。

2. 四件套技术栈为什么这样配：选型不是凑热闹

SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0 这套组合在目前的 Java Web 项目里出现频率非常高。它选型逻辑很简单：每一层都有成熟方案，组合起来不需要写太多胶水代码。但“用”和“会用”是两回事，下面把每个组件在系统里承担的角色说清楚。

2.1 SpringBoot2：用约定代替配置，启动成本低

SpringBoot2 对写业务系统的人来说，最大的价值是“自动配置”和“生态成熟”。你不需要再像 SSM 一样手写一堆 XML 配置文件，大部分组件只要引入依赖、配好连接信息，启动时就能自动装配。这套考勤系统里涉及 Web、数据源、校验、文件上传等能力，SpringBoot2 都能直接支持。

版本选择上，我用的是 2.7.x 系列，动态选择一个稳定版本很重要。3.x 出来后虽然新，但部分第三方组件和教程还停留在 2.x，对课程设计和毕设来说，稳定优先。SpringBoot2 的另一个好处是内置 Tomcat，本地启动不需要额外配置容器，后期部署只需要一个 jar 文件。

2.2 MyBatis-Plus：单表操作不用写 SQL，但别滥用

MyBatis-Plus 给我的第一感受就是“电动螺丝刀代替手动螺丝刀”。BaseMapper 里已经内置了 insert、updateById、deleteById、selectById 这些通用方法，单表 CRUD 基本不用写 SQL。在考勤系统里，用户表、班级表、课程表的增删改查都是标准单表操作，用 MyBatis-Plus 确实能省大量时间。

但也要注意，MyBatis-Plus 不适合无脑使用。考勤统计涉及多表关联、分组聚合、子查询，这些场景我仍然会写 XML 和自定义 SQL。它的 LambdaQueryWrapper 虽然链式写法很优雅，但遇到复杂查询时，可读性会迅速下降。我的建议是，单表查询用 Wrapper，多表统计写 XML，分页用自带的 Page，这样既高效又不失控。

2.3 Vue3 + Element Plus：页面交互更灵活，开发体验更顺手

前端选择 Vue3，最直观的变化是组合式 API。用 <script setup> 语法后，组件逻辑可以按功能点组织，不像 Vue2 的 options API 那样数据和生命周期分散在固定位置。这个考勤项目里，签到页需要同时处理定时器、当前课程信息、签到按钮状态、地理位置校验，用一个 ref 加几个函数就能串起来，思路比 Vue2 清晰很多。

Element Plus 是 Element UI 的 Vue3 版本，后台管理系统常见的表格、表单、日期选择器、对话框都有现成组件。考勤统计页面用 el-table 展示班级出勤数据，再用 el-card 做统计卡片，半小时就能搭出一个不错的界面。组件库选它还有一个原因：文档和示例比较完整，遇到布局问题直接查文档，不用瞎试。

2.4 MySQL8.0：不是版本越高越装，是要用它的新能力

MySQL8.0 相比 5.7，在考勤统计场景里有两个很实用的能力：窗口函数和 JSON 字段。统计每个学生的出勤排名可以用 ROW_NUMBER()，这类需求在 5.7 里要写子查询加临时变量，很麻烦。数据库字段里如果有些扩展信息不固定，比如教师自定义签到规则，可以直接用 JSON 类型存，不需要频繁改动表结构。

当然，选 MySQL8.0 还有一个现实原因：新机器上安装和初始化越来越方便，很多云数据库默认就是 8.0。需要注意驱动配置不能再用旧的 com.mysql.jdbc.Driver，要改成 com.mysql.cj.jdbc.Driver，同时时区参数必须配置对。这个问题后面我会单独展开。

3. 数据库设计：一张签到记录表怎么支撑考勤统计

数据库设计是这类系统的核心，也是很多同学容易轻视的部分。代码跑起来容易，但表结构设计不合理，到统计阶段就会出现“查不到数据”“统计不准”“改动字段影响一大片”的问题。这套源码的表结构不算复杂，但关系清晰，可以直接参考。

3.1 核心表结构与关系

考勤系统至少要有这几张表：用户表、角色表、班级表、课程表、签到记录表、请假记录表。用户表和角色表是多对多，需要一张用户角色关联表；课程表关联班级，也是一张关联表，表示“某课程对某班级开放”；签到记录表是核心，应该记录学生、课程、日期、状态、签到时间等字段。

这里我给一张简化版的关系表，方便你对照源码看：

这个设计的好处是：课程与班级独立管理，一个课程可以同时给多个班级上课，一个学生也能选多门课程。签到表通过 course_id + record_date + student_id 唯一约束保证一天一门课只有一条记录，避免重复签到。

3.2 签到状态字段：用数字字典代替字符串

签到状态如果直接存“正常”“迟到”“缺勤”，后面统计会非常难受。字符串容易写错，而且无法直接做数值运算。这套系统里状态用 TINYINT 类型，0 表示待签到，1 表示正常，2 表示迟到，3 表示早退，4 表示缺勤，5 表示请假，6 表示补签。代码里定义枚举类，页面展示时再把数字翻译成文字。

用一个数字字典的好处是统计 SQL 可以写得很简洁。比如统计某门课的出勤率，直接用 SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END)，不需要 LIKE '%正常%' 这种模糊匹配。而且将来如果要扩展“因公外出”这种状态，只需要加一个枚举值，统计 SQL 也更好维护。

3.3 自动填充、逻辑删除与唯一索引

MyBatis-Plus 在操作数据库时有两个常用能力：字段自动填充和逻辑删除。签到记录表里有 create_time 和 update_time 两个字段，按传统写法每次 insert 和 update 都要手动 set 当前时间，MyBatis-Plus 可以写一个 MetaObjectHandler 实现自动填充，代码里就不用再管时间戳。

逻辑删除是另一个容易被误解的地方。很多项目用 @TableLogic 给所有表加一个 deleted 字段，查询时自动带 WHERE deleted = 0。好处是避免物理删除导致历史数据丢失，对毕设项目来说比较安全。但要注意，唯一索引不能直接建在业务字段上，因为你删除一条记录后，同一个业务字段再插入时会因为唯一索引冲突导致失败。我的处理方式是唯一索引里包含逻辑删除字段，或者把 deleted 默认值设计成 0，删除后改为记录主键的负值，这在真实项目里叫“假删除配合唯一索引”，虽然有点技巧，但能解决实际问题。

签到表的核心建表语句可以参考下面这种写法：

sql复制CREATE TABLE attendance_record (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  student_id BIGINT NOT NULL COMMENT '学生用户ID',
  course_id BIGINT NOT NULL COMMENT '课程ID',
  record_date DATE NOT NULL COMMENT '签到日期',
  status TINYINT NOT NULL DEFAULT 0 COMMENT '签到状态：0待签到 1正常 2迟到 3早退 4缺勤 5请假 6补签',
  sign_time DATETIME NULL COMMENT '实际签到时间',
  create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  deleted TINYINT NOT NULL DEFAULT 0,
  UNIQUE KEY uk_student_course_date (student_id, course_id, record_date)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='考勤签到记录表';

utf8mb4 是 MySQL8.0 下推荐的字符集，能直接存表情符号，也能兼容中文。唯一索引在这里的意义非常关键：后端接口即使没有做防重逻辑，数据库层面也不会出现同一天重复签到记录。运行时如果捕获到 DuplicateKeyException，就能立刻告诉用户“今日已签到”。

4. 后端接口：登录、打卡、统计三条主链路的实现

数据库设计好之后，后端的主链路就清晰了。这套系统的后端没有做花哨的微服务架构，而是标准单体应用加分层结构：Controller、Service、Mapper。下面挑三条最核心的链路说。

4.1 JWT 登录与拦截器鉴权

前后端分离项目里，登录状态不能依赖 Session，因为前端和后端可能不在同一个域下。这套系统用的是 JWT，用户登录成功后后端返回一个 token，前端把 token 存在本地存储里，之后每次请求在 Header 里带上 Authorization: Bearer <token>。

后端用一个拦截器统一处理 token 校验。拦截器里先放行登录接口和一些静态资源白名单，其余请求都解析 token，解析失败直接返回 401。解析成功后把用户 ID 和角色信息塞进请求上下文，方便 Controller 里获取当前登录人。这里要注意，JWT 的秘密不能写死在代码里，应该放在配置文件中，部署时通过环境变量覆盖。

登录接口的代码结构大致是这样的：

java复制@PostMapping("/login")
public Result<String> login(@RequestBody LoginDTO dto) {
    // 1. 校验用户名密码
    User user = userService.login(dto.getUsername(), dto.getPassword());
    // 2. 生成JWT
    String token = JwtUtil.createToken(user.getId(), user.getRoleCode());
    // 3. 返回给前端
    return Result.success(token);
}

密码存储不能用明文。项目里使用了 BCrypt 加密，数据库里的密码是一串带随机盐的哈希值。这样做的好处是即使数据库泄露，密码也无法直接还原。如果你拿到手的源码里密码是明文的，强烈建议改成 BCrypt，这会是你答辩时能讲出来的一个安全亮点。

4.2 签到接口如何防止重复打卡

签到接口是考勤系统里并发压力最大、也最容易出 bug 的接口。学生可能在 10 分钟内反复点签到按钮，也可能同时用手机和电脑登录，前端按钮做了防抖还不够，后端必须兜底。这个项目的第一层防线是数据库唯一索引，第二层防线是插入前查询一次当天的记录。

伪代码逻辑是这样：

java复制public void sign(SignDTO dto) {
    // 1. 校验当前时间是否在签到窗口内
    Course course = courseService.getById(dto.getCourseId());
    Date now = new Date();
    if (now.before(course.getSignStartTime()) || now.after(course.getSignEndTime())) {
        throw new BizException("不在签到时间范围内");
    }
    // 2. 查询当天是否已有记录
    Long count = attendanceRecordService.lambdaQuery()
            .eq(AttendanceRecord::getStudentId, dto.getStudentId())
            .eq(AttendanceRecord::getCourseId, dto.getCourseId())
            .eq(AttendanceRecord::getRecordDate, DateUtil.today())
            .count();
    if (count > 0) {
        throw new BizException("您今日已签到，请勿重复操作");
    }
    // 3. 根据当前时间判定状态
    int status = determineStatus(course, now);
    // 4. 插入记录
    AttendanceRecord record = new AttendanceRecord();
    // ... 设置字段
    attendanceRecordService.save(record);
}

判断迟到和早退的逻辑也很关键。签到时间如果晚于课程开始时间但早于“迟到阈值时间”，状态记为迟到；如果签到时间已经超过“缺勤阈值时间”，直接记为缺勤。这里的所有阈值都来自配置表，不在代码里写死。

4.3 考勤统计的聚合查询与导出

统计模块的分页查询用的是 MyBatis-Plus 的 Page，多表聚合的部分写自定义 SQL。比如统计某门课程每个学生的签到情况，SQL 可以这样写：

sql复制SELECT
    u.real_name AS studentName,
    c.class_name AS className,
    COUNT(a.id) AS totalCount,
    SUM(CASE WHEN a.status = 1 THEN 1 ELSE 0 END) AS normalCount,
    SUM(CASE WHEN a.status = 2 THEN 1 ELSE 0 END) AS lateCount,
    SUM(CASE WHEN a.status = 4 THEN 1 ELSE 0 END) AS absentCount
FROM attendance_record a
LEFT JOIN sys_user u ON a.student_id = u.id
LEFT JOIN class_info c ON u.class_id = c.id
WHERE a.course_id = #{courseId}
GROUP BY a.student_id, u.real_name, c.class_name

查询结果直接用 Page<Map<String, Object>> 返回，前端拿到后渲染表格。导出 Excel 我推荐用 EasyExcel 或 Hutool 的 ExcelWriter，实体类上加 @ExcelProperty 注解，导出代码十几行就能搞定。答辩时直接现场演示导出功能，效果非常加分。

提示：统计模块一定要区分权限。学生只能查自己，教师能查自己授课的班级，管理员才能查全量数据。如果统计接口没有做数据权限控制，学生传一个 courseId 就能看到所有人的出勤记录，这种漏洞在评审时很容易被指出来。

5. Vue3 前端：页面结构与接口联调经验

后端接口再丰富，前端联调不顺畅，项目一样白搭。这个系统前端用 Vue3 + Vite + Element Plus + Pinia，整体结构比较标准。下面把前端最关键的几个点讲清楚。

5.1 前端目录结构与管理路由

前端项目不是把所有页面堆在 views 目录里就完事，而是按角色拆分成 views/admin、views/teacher、views/student 三个子目录，每个子目录里再放对应功能的页面。路由也分为静态路由和动态路由。静态路由就是登录页、首页、404 这些，动态路由根据用户角色从后端获取菜单数据后，用 router.addRoute 动态注册。

权限路由的好处是，学生直接手动访问 /admin/user 路径时，前端会先判断角色，没有权限就跳转到 403 页面。不过我还是想强调一遍，前端只能解决体验问题，真正的安全校验必须靠后端接口权限。哪怕前端路由没有拦截，接口也要能够拒绝无权限请求。

5.2 Axios 封装与 Token 注入

前端和后端通信一般都会封装一个 request.js，核心是创建一个 Axios 实例，然后在请求拦截器里把 token 加进去。响应拦截器做统一错误处理，比如 401 时跳到登录页，其他错误弹个消息提示。这样可以避免在每个页面都写重复的错误处理代码。

简单的封装片段：

javascript复制import axios from 'axios'
import { ElMessage } from 'element-plus'
import router from '@/router'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

request.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = `Bearer ${token}`
  }
  return config
})

request.interceptors.response.use(
  response => response.data,
  error => {
    if (error.response?.status === 401) {
      localStorage.removeItem('token')
      router.push('/login')
    } else {
      ElMessage.error(error.response?.data?.message || '请求失败')
    }
    return Promise.reject(error)
  }
)

export default request

项目里所有接口都通过这个 request 实例调用，代码风格统一，排查问题也方便。localStorage 存储 token 有一个隐患是 XSS 攻击可能读取到，但课程设计和毕设场景下，这个方案胜在简单。如果你想做更好，可以把 token 放在内存里并用 Pinia 管理，刷新页面后重新从后端换取 token，但复杂度会高一些。

5.3 签到页面与实时统计展示

学生端签到页是这个系统最核心的交互页面。界面用 el-calendar 展示本月签到记录，已签到的日期打上绿色标记，缺勤日期显示红色。当天的课程卡片展示课程名称、上课时间、签到状态，以及当前是否处于签到窗口内。如果窗口已开启，按钮显示“立即签到”；如果还没到时间，按钮置灰；如果已经签过，按钮显示“已签到”。

这里有一个小技巧：签到窗口开启时，前端可以用定时器每隔 30 秒调用一次“查询当前可签到课程”的接口，判断签到状态是否变化。但要注意，定时器在用户离开页面时要记得清除，否则后台会一直发请求，很影响体验。我习惯用 Vue3 的 onBeforeUnmount 钩子清掉定时器。

统计页面的卡片用计算属性实时算出来，比如总出勤率、迟到次数、最近一周缺勤趋势。班级维度的统计用 el-table 加 el-progress 展示，学生一多也不会卡。前端展示的交互细节很多，真正动手跑一遍会比只看文档理解得快很多。

6. “含文档”到底包含什么，怎么靠文档快速跑通

标题里特别写了“含文档”，这一点在源码项目里其实很关键。很多源码只给代码不给文档，用户拿到后靠猜，连数据库初始化都费劲。这套系统的文档覆盖了从需求背景到部署上线的完整链路，拿到手后按文档顺序操作，基本不用瞎猜。

6.1 文档目录：一份完整项目文档应该有哪些内容

一份能帮人快速上手的文档，至少要包含五部分：项目介绍与需求说明、数据库设计说明书、接口文档、部署文档、操作手册。

项目介绍里会写清楚系统面向什么场景、有哪些核心功能模块和角色；数据库设计说明书里包含表结构说明、ER 图和字段字典；接口文档把每个接口的请求参数、响应参数、错误码列出来；部署文档负责让用户能在一台新机器上把系统跑起来；操作手册则是给最终使用者看的，比如教师如何发起签到、学生如何请假。这套源码的文档虽然不算特别厚，但该有的内容都有，尤其数据库设计部分画了 ER 图，对理解表关系帮助很大。

6.2 快速上手的标准顺序

拿到任何带文档的源码，我建议都按这个顺序操作，能省掉大量返工时间。

第一步，先读 README 或部署文档，搞清楚环境要求，比如 JDK 版本、Maven 版本、Node 版本、MySQL 版本。版本不匹配会在启动时报各种奇怪的错误。第二步，初始化 SQL 脚本。用 Navicat 或命令行执行 init.sql，确认数据库、表、初始数据都创建好了。第三步，修改后端配置文件，主要是数据库连接地址、账号密码、JWT 密钥等。第四步，启动后端 SpringBoot 应用，看到“Started Application”日志后，用 Swagger 或 Apifox 测试登录接口，拿到 token。第五步，启动前端，执行 npm install 和 npm run dev，浏览器访问页面，用初始化账号登录。

这个顺序的核心逻辑是：先把基础环境跑通，再测接口，最后连页面。如果顺序颠倒，前端页面白屏时你很难判断是接口问题还是页面代码问题。

6.3 自己动手补文档的建议

如果你是拿这套源码二次开发，建议也把文档同步补起来。接口文档用 Apifox 或 Postman 管理，导出成 Markdown 或 OpenAPI 格式，放到项目 docs 目录下。数据库设计文档不用单独画图，把每个表的字段注释写准确，再在 README 里放一段关系说明，就很够用了。

答辩时老师经常问的问题是“系统有哪些表，为什么这样设计”。如果你的文档里能拿出 ER 图和字段字典，再加上实践中的解释，这个问题的可信度会高很多。所以“含文档”不仅仅是卖点，也是学习项目的好帮手。

7. 跑通这套源码时我踩过的三个环境坑

这部分是我最想分享的内容。技术代码本身不难，难的是环境不一致导致的隐性问题。我把跑这套系统时遇到的问题整理成三条，每一条网上都有很多人中招。

7.1 MySQL8.0 时区问题导致的时间错乱

第一次启动后端时，控制台直接报 The server time zone value ... is unrecognized。这是因为 MySQL8.0 默认时区是 UTC，和本地时间相差 8 小时。如果不在连接串里指定时区，插入数据库的时间会比实际时间少 8 小时，考勤系统对时间非常敏感，差 8 小时意味着签到判断全部错误。

解决方案是修改 application.yml 里的 JDBC 连接串：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/attendance?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
    username: root
    password: yourpassword
    driver-class-name: com.mysql.cj.jdbc.Driver

另外还要检查 MySQL 自身的时区设置，可以在 MySQL 命令行里执行 SELECT NOW();，如果返回的时间和本地时间不一致，就先设置全局时区。这个问题解决后，签到记录的 create_time 才对得上。

7.2 MyBatis-Plus 分页插件没配导致的分页失效

考勤统计列表用的是自定义 SQL 加 Page 参数，但一开始分页没有生效，数据把全表都查出来了。原因是 MyBatis-Plus 的分页功能不是默认开启的，需要单独配置 MybatisPlusInterceptor，并把 PaginationInnerInterceptor 添加进来。

配置类大概是这样的：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

配置完之后，分页参数必须放在第一个查询参数的位置，否则 Page 对象不会生效。这个坑很容易踩，因为代码不报错，只是返回的数据量不对。如果你用的是自定义 XML SQL，还要确保 Mapper 方法的返回类型是 Page<T>，而不是 List<T>。

7.3 前端跨域与登录状态丢失

前端开发服务器跑在 5173 端口，后端跑在 8080 端口，直接请求会跨域。许多源码自带跨域配置，但如果你拿到手的是精简版，就要自己处理。前端最简单的方式是在 Vite 里配置 server.proxy，把 /api 开头的请求转发到后端地址，避免浏览器产生跨域。

Vite 配置示例：

javascript复制export default {
  server: {
    port: 5173,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

如果后端也配置了 CORS，要小心 Access-Control-Allow-Origin 和前端 token 是否匹配。登录状态丢失最常出现在 token 过期或刷新后 localStorage 被清空。我的建议是统一在 Axios 响应拦截器里处理 401，不要在每个页面单独判断。

这三个坑解决之后，整套系统基本就能稳定跑起来了。如果你也拿到一套类似技术栈的源码，建议按我刚才说的顺序先读文档、初始化数据库、再起后端、最后连前端，遇到环境问题先看版本和时区。跑通之后，你会发现 SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0 这套组合的设计思路非常清晰，很多后台管理系统都可以复用这套骨架。