SpringBoot+Vue大学生考勤系统毕设：从表结构到接口联调完整实操指南

作为带过不少Java Web毕设的过来人，考勤系统这个题材在每年的毕业设计里出场率一直很高，但真正能让我觉得“拿得出手”的项目并不多。大多数同学的版本要么是纯JSP老古董，要么是只做了个简单CRUD，答辩时经不起追问。这次拆解的这套SpringBoot+Vue大学生考勤系统平台，属于结构完整、文档齐全、可以直接跑起来二次开发的那种项目，源码、SQL脚本、接口文档三件套全都有，很适合作为Java Web方向的毕设参考。这篇文章我尽量把项目背后的设计思路、核心表结构、接口约定、运行配置以及常见坑一次讲清楚，给正在选题或者已经拿到这类项目的同学做一个完整的实操指南。

1. 毕设选题背后的需求拆解与方案选型

1.1 大学生考勤场景的核心痛点

先想清楚一个问题：为什么很多学校、很多导师都认可考勤系统作为毕设题目？因为考勤不是一个纯业务系统，它天然具备“数据采集—规则判定—统计展示”的完整闭环。

大学课堂考勤和公司打卡有几个明显区别。第一，上课地点分散，可能是教学楼、实验楼、操场，甚至线上课堂，所以考勤方式不能死板地只依赖某个固定设备。第二，人员角色多，学生、任课教师、辅导员、院系管理员对考勤数据的诉求各不相同——学生要查自己的缺勤记录，教师要给所授课程录入考勤，辅导员要关注所带班级的整体出勤率，管理员则要维护基础数据和生成汇总报表。第三，缺勤规则复杂，有的课程允许三次迟到算一次旷课，有的课程请假需要提前申请并经过审批，期末成绩里的平时分往往直接挂钩出勤率。

秒懂的需求模型是：这个系统本质是一个“多角色、多规则、数据驱动”的管理平台。作为毕设，它能覆盖前端展示、后端业务、数据库设计、接口联调、权限控制等几乎所有Java Web课程的核心知识点，这也就是为什么它被称为“用一套题目练完整个技术栈”的典型项目。

1.2 技术选型为什么落在SpringBoot+Vue

技术选型不是越新越好，而是越适合“把自己的能力展示清楚”越好。

后端选择SpringBoot，核心原因是它极大地降低了SSM整合的复杂度。传统的SSM项目需要手动配置大量的XML文件，一个数据源配置、事务配置、Mapper扫描配置就可能磨掉一个星期的耐心。SpringBoot通过自动配置和starter机制，让一个Web项目从零到能跑只需要一个启动类加几行依赖。给考勤系统用SpringBoot，省下来的时间可以全部投入在真正的业务逻辑上。

前端选择Vue，理由也很现实。Vue的学习曲线在主流框架里算平缓的，模板语法贴近传统HTML开发习惯，组件化又能让页面结构清晰。配合Vue Router实现页面跳转、Vuex或Pinia管理登录状态、Axios发请求，一个典型的前后端分离项目就完整了。考勤系统的前端页面量不算多——登录页、首页、考勤记录页、请假页、管理页、统计图表页——用Vue完全可以手工维护，不需要引入太重的框架。

前后端分离的架构还有一个隐藏的好处：答辩时方便演示。你可以在本地同时启动后端和前端，也可以把前端打包后放进后端静态资源目录里，甚至可以只启动后端，用接口文档工具直接演示每个API的输入输出。这种灵活性在答辩现场能帮大忙。

1.3 项目范围与功能模块的边界

一个合格的毕设项目，最难的是控制范围。范围太大容易虎头蛇尾，范围太小又显得工作量不足。

大学生考勤系统平台比较好的模块拆分方式是这样：

• 基础数据管理：学生信息、教师信息、班级信息、课程信息的维护。
• 考勤业务管理：学生签到、教师录课、请假申请与审批、缺勤记录生成。
• 统计与查询：按学生、按课程、按班级维度的出勤统计，支持图表展示。
• 系统权限管理：登录认证、角色区分、页面级权限控制。

这里面不要轻易上“人脸识别打卡”“GPS定位签到”之类的高大上功能——不是说不能做，而是这些功能会牵扯出大量工程问题（人脸模型怎么训练、定位偏差怎么容忍），很容易把主线的学分和精力都耗掉。如果导师要求创新点，可以在“规则引擎”上做轻度扩展，比如把迟到几次算旷课、请假扣不扣出勤率这类参数抽成可配置的规则，比堆砌硬核功能更契合毕设评价标准。

2. 数据结构设计与SQL脚本解读

2.1 核心数据表的设计思路

拿到这套项目的SQL脚本时，先别急着执行，先把表结构看一遍。考勤系统的表设计是否合理，直接决定了后续业务逻辑好写不好写。

典型的核心表包括用户表、学生表、教师表、课程表、选课表、考勤记录表、请假表、审批记录表。其中用户表是最关键的一张表，因为它承载了登录认证和角色区分。

用户表常用设计如下：

密码不要用明文存储，这是答辩老师大概率会问的问题。SpringBoot里引入spring-security-crypto依赖，用BCryptPasswordEncoder做加密和校验是最省事的方式。如果你用的是MyBatis-Plus，UserMapper里写一个根据用户名查用户的接口，登录时用QueryWrapper即可。

学生表和教师表不要和用户表合并成一张大表，原因很简单：学生有学号、班级、年级等专属字段，教师有职称、所属院系等字段，放在一起会导致大量字段稀疏，而且角色扩展性差。正确做法是用户表存登录凭证和通用身份字段，学生表和教师表通过user_id字段与用户表关联。

考勤记录表是整个系统的核心流水表，设计上需要重点关注。它一定要包含学生ID、课程ID、上课日期、考勤状态（正常、迟到、早退、缺勤）、签到时间、录入方式等字段。这张表的索引设计也有讲究，按学生ID和课程ID组合建索引，可以大幅提速日常查询。

2.2 用SQL脚本初始化数据库的步骤

拿到SQL脚本后，在本地初始化数据库需要注意几个细节。

第一步，创建数据库。脚本里通常不会帮你创建Database，需要手动执行：

sql复制CREATE DATABASE IF NOT EXISTS attendance_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

使用utf8mb4而不是utf8，是经验之谈。考勤系统里学生姓名虽然大概率是中文，但“备注”字段可能包含表情符号，虽然概率低，但utf8mb4能真正兼容四字节UTF-8字符，避免写入失败。

第二步，按依赖顺序执行表创建脚本。父表先建，子表后建。典型的依赖顺序是：用户表、班级表、学生表、教师表、课程表、选课表、考勤表、请假表。SQL脚本里一般已经排好顺序，但如果你是手动执行的，看到“外键约束失败”的报错不用慌，通常是建表顺序不对。

第三步，检查种子数据。一个优秀的毕设项目SQL脚本不仅仅包含表结构，还会附带演示数据——几个学生账号、教师账号、管理员账号，预设的课程和选课关系，甚至一批模拟的考勤记录。这些数据的作用是为了让项目跑起来之后有东西可看，不至于登录进去全是空白页面。

提示

种子数据的密码建议统一为初始密码，例如123456，并使用和注册时相同的BCrypt加密结果。如果你不想用脚本里给的加密串，可以在项目启动后调用一次注册接口，把生成的密码哈希值替换回SQL脚本里。

2.3 表结构与业务逻辑的匹配关系

看一个考勤项目写得好不好，别只看它有多少张表，要看“请假流程”是怎么用表支撑的。

比较完善的请假设计会拆成两张表：请假申请表（记录谁请了假、从哪节课到哪节课、请假原因、状态）和审批记录表（记录谁审批了、审批意见、审批时间）。为什么拆两张？因为一张请假申请可能经过多级审批——教师初审、辅导员终审，审批记录表天然就是一对一多的关系。简化版项目可能只在请假申请表中加一个approver_id字段，但这会丢失审批历史，答辩时很容易被“如果辅导员不同意，教师已经同意了怎么办”这类问题问倒。

考勤记录表的设计同样要和“课堂点名”业务匹配。一次点名针对的是某门课程某一次课的多个学生，所以考勤记录表必须携带course_id、student_id、class_date这三个核心定位字段。如果再加一个course_schedule_id（课时ID）会更好，但前提是项目里有“课时表”这种设计。基础毕设里没有课时表，直接用课程ID+日期定位一次课，也就够了。

SQL脚本中的视图或联表查询语句也值得研究。比如“查询某学生某门课程的出勤汇总”，正确姿势是：

sql复制SELECT
    c.course_name,
    COUNT(*) AS total_count,
    SUM(CASE WHEN a.status = 1 THEN 1 ELSE 0 END) AS normal_count,
    SUM(CASE WHEN a.status = 2 THEN 1 ELSE 0 END) AS late_count,
    SUM(CASE WHEN a.status = 3 THEN 1 ELSE 0 END) AS absent_count
FROM attendance_record a
JOIN course c ON a.course_id = c.id
WHERE a.student_id = #{studentId}
GROUP BY c.course_name;

课堂上要讲的“SQL分组聚合”知识，在这一个查询里就全部覆盖了。

3. 核心业务接口设计规范与实现拆解

3.1 统一返回体与接口约定

前后端分离项目，第一步一定是约定接口返回格式。没有统一格式，前端拿到数据就得写一堆if else判断，项目越到后面越难维护。

这套考勤系统里，最基础也最重要的类是统一返回体。通常定义为：

java复制public class Result<T> {

    private Integer code;

    private String message;

    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("操作成功");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

这里的code建议和HTTP状态码做一个语义区分。HTTP状态码管的是网络层面的通信状态（200成功、404资源不存在），业务状态码管的是业务层面的结果（200成功、401未登录、403无权限、500业务异常）。两层混在一起，排查问题会非常痛苦。

后端所有Controller的返回值都统一包装成Result结构。例如登录接口：

java复制@PostMapping("/login")
public Result<LoginVO> login(@RequestBody LoginDTO loginDTO) {
    LoginVO loginVO = userService.login(loginDTO);
    return Result.success(loginVO);
}

前端Axios封装里，通过拦截器统一处理状态码：

javascript复制service.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code !== 200) {
      Message.error(res.message || '请求失败')
      return Promise.reject(new Error(res.message))
    }
    return res
  },
  error => {
    if (error.response && error.response.status === 401) {
      router.push('/login')
    }
    return Promise.reject(error)
  }
)

这种设计最大的好处是前端逻辑很薄——所有页面只需要关心业务数据，不用在每个接口调用的地方重复处理错误弹窗。

3.2 登录鉴权与JWT实现要点

考勤系统涉及三种角色，登录鉴权是绝对逃不掉的设计题。这里用的方案是JWT令牌鉴权。

JWT的基本原理不复杂：用户登录成功后，后端用密钥签发一个包含用户ID、用户名、角色和过期时间的token字符串返回给前端；前端将token保存在localStorage里，并在后续每次请求的请求头中带上Authorization字段；后端通过拦截器解析token，确认用户身份并获取角色信息。

核心拦截器实现思路如下：

java复制@Component
public class JwtInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        if (StringUtils.hasText(token) && token.startsWith("Bearer ")) {
            String realToken = token.substring(7);
            try {
                Claims claims = JwtUtil.parseToken(realToken);
                request.setAttribute("userId", claims.get("userId"));
                request.setAttribute("role", claims.get("role"));
                return true;
            } catch (Exception e) {
                // token过期或无效，返回401
                response.setStatus(401);
                return false;
            }
        }
        response.setStatus(401);
        return false;
    }
}

不要忘了配置放行白名单，登录接口、注册接口、以及前端的静态资源请求不应该进拦截器。在WebConfig里配置：

java复制@Override
public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(jwtInterceptor)
            .addPathPatterns("/**")
            .excludePathPatterns("/api/auth/login", "/api/auth/register", "/error");
}

前端路由守卫配合后端拦截器，形成完整闭环：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.path !== '/login' && !token) {
    next('/login')
  } else {
    next()
  }
})

这样的前后端双重鉴权，既保证了接口安全性，也让前端页面跳转体验更好。答辩时把这一套讲清楚，技术含量立刻就不一样了。

3.3 考勤签到接口的完整链路

“学生签到”是考勤系统最核心的接口。给它设计一个完整链路，能体现你对业务的理解深度。

常规的签到流程是：前端点击“签到”按钮，把学生ID、课程ID、当前时间传给后端；后端逐层处理——检查该学生是否选了这门课、检查当前时间是否在上课时间段内、检查当天是否已经签到过、将签到记录写入考勤表。部分项目会支持教师端录入，就是教师替学生打考勤，这时候“录入方式”字段要能区分教师代录和学生自签。

写签到接口时，特别注意两个校验：重复签到的防重校验。如果前端没做防抖，用户手抖连点两次签到，就可能插入两条记录。前端的按钮loading可以解决一半问题，后端的数据库唯一索引才能兜底。比较实用的做法是给考勤记录表加一个联合唯一索引：

sql复制ALTER TABLE attendance_record
ADD UNIQUE KEY uk_student_course_date (student_id, course_id, class_date);

加了这个索引之后，重复插入的请求会直接报DuplicateEntry错误，后端捕获这个异常并返回“今日已签到”的提示，比任何代码逻辑都可靠。这个细节非常值得在博客或答辩里专门提一句，因为绝大多数毕设都不会做这一层防重。

3.4 请假模块的状态机设计

请假模块最怕的就是状态字段乱跳。请假单状态从“待审批”到“已通过”“已拒绝”，再到“已撤销”，如果全靠前端按钮控制，后端的校验逻辑会出现大量漏洞。

正规做法是用状态机思想限制状态流转。定义合法的状态转换路径：

• 待审批：允许撤销、允许审批通过、允许审批拒绝
• 已通过：不允许再做任何操作
• 已拒绝：不允许再做任何操作
• 已撤销：不允许再做任何操作

后端审批接口实现时，先查出请假单当前状态，再用if判断目标状态是否为合法下一步。

java复制if (leaveOrder.getStatus() != 0) {
    throw new BusinessException("当前状态不可审批");
}

设计一个简单的状态枚举：

java复制public enum LeaveStatus {
    PENDING(0, "待审批"),
    APPROVED(1, "已通过"),
    REJECTED(2, "已拒绝"),
    CANCELED(3, "已撤销");

    private final int code;
    private final String desc;
}

这样不仅业务清晰，答辩讲解时也容易说清楚。

请假审批通过后，要和考勤记录产生联动——一个合理的设计是在审批通过时，自动把请假时间段对应的考勤记录状态改为“请假”，保证统计报表里学生不会因为请假被算成缺勤。这个联动逻辑也是答辩时可以展开讲解的设计点。

3.5 Excel导出与统计报表的实现思路

期末出勤统计和汇总导出是考勤系统的高频需求，也往往被很多毕设项目忽略。一个完整度高的项目，至少要做两件事：按条件查询考勤汇总数据，将结果导出为Excel。

后端导出Excel，用EasyExcel或Apache POI实现。如果你已经在项目里引入了SpringBoot，用EasyExcel更省事：

java复制@RequestMapping("/export")
public void export(HttpServletResponse response) {
    List<AttendanceStatisticVO> list = attendanceService.statisticList(queryDTO);
    String fileName = URLEncoder.encode("考勤统计.xlsx", "UTF-8");
    response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet");
    response.setCharacterEncoding("utf-8");
    response.setHeader("Content-Disposition", "attachment;filename=" + fileName);
    EasyExcel.write(response.getOutputStream(), AttendanceStatisticVO.class)
            .sheet("考勤统计")
            .doWrite(list);
}

前端展示统计数据，用ECharts是很成熟的方案。考勤系统常见的可视化图表包括：课程出勤率柱状图、学生缺勤次数排名条形图、班级出勤率趋势折线图。ECharts配置不难，关键是数据格式要设计好——后端统计接口直接返回适合图表使用的扁平结果，前端拿到后按series格式组装。

4. 接口文档的编写规范与前后端协作

4.1 为什么接口文档是毕设的加分项

我见过太多毕设项目，源码写完了，接口文档却一个字没有。等到写论文时，只能回头翻Controller代码回忆接口长什么样。这样效率极低，而且答辩老师一旦问到“你如何保证前后端协作顺畅”，没有文档支撑的回答往往缺乏底气。

接口文档的好处不止在于让别人看懂，它还能倒逼你把接口设计得更合理。当你需要为每个接口写出它的请求参数、返回格式、错误码时，你就会自然发现接口设计中的别扭之处并主动修正。

目前主流的做法是使用Apifox或Postman。Apifox的优势在于把接口调试和文档管理合并在一起，还支持导入OpenAPI/Swagger格式。对于SpringBoot项目，一个省力的路径是引入springdoc-openapi依赖，通过注解自动生成OpenAPI文档，再用Apifox导入。但这套方案需要额外学习和时间成本，如果只是毕设，手写文档或直接用Apifox粘贴示例也完全够用。

4.2 关键接口的文档示例

一份合格的接口文档，每个接口至少应包含：接口名称、请求路径、请求方式、请求参数说明、返回示例。

以“分页查询考勤记录”接口为例：

text复制接口名称：分页查询考勤记录
请求路径：GET /api/attendance/page
请求参数：
- pageNum：页码，从1开始，必填
- pageSize：每页条数，必填
- studentId：学生ID，选填，传入后只查该学生的记录
- courseId：课程ID，选填
- status：考勤状态，选填，1正常 2迟到 3缺勤 4请假
返回示例：
{
  "code": 200,
  "message": "操作成功",
  "data": {
    "total": 65,
    "list": [
      {
        "id": 1024,
        "studentName": "张三",
        "courseName": "Java程序设计",
        "classDate": "2025-11-10",
        "status": 2,
        "createTime": "2025-11-10 09:41:02"
      }
    ]
  }
}

接口命名遵循RESTful风格，这一点看起来简单，实际操作中很多人会犯错误。分辨一下：/api/dept/list 是动词，/api/departments 是名词。RESTful风格推荐用名词加HTTP方法表达语义：

RESTful风格不是强制标准，但如果整个项目能保持统一风格，代码的可读性和专业度立刻提升一个档次。

4.3 联调阶段的错误排查方法

前后端分离项目联调时，90%的问题集中在三类：跨域（CORS）、请求参数格式不对、返回数据格式不匹配。

跨域问题的典型表现是浏览器控制台报CORS错误。SpringBoot的解法是在配置类里加一个CorsFilter：

java复制@Configuration
public class CorsConfig {

    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOriginPattern("*");
        config.addAllowedMethod("*");
        config.addAllowedHeader("*");
        config.setAllowCredentials(true);
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

注意，如果使用了拦截器，要确保拦截器在CorsFilter之后执行，或者拦截器对OPTIONS预检请求直接放行，否则预检请求会被拦截器挡住，造成“明明配置了跨域但还是报错”的诡异问题。拦截器里加一行判断：

java复制if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
    return true;
}

请求参数格式不对的问题也很常见。后端用@RequestBody接收JSON对象，前端却用URLSearchParams提交表单数据；或者前端Axios没有设置Content-Type为application/json；或者日期字段传的是String，后端的LocalDateTime解析失败。这些问题查起来都不难，套路是先在浏览器F12的Network面板里看请求Payload长什么样，再对比后端接收的字段名，大部分情况一眼就能定位。

5. 本地环境搭建与项目运行全流程

5.1 JDK、Maven、Node.js环境准备

这个项目要跑起来，本地环境需要三件套：JDK、Maven、Node.js。

JDK版本是这第一步的第一个坑。SpringBoot 2.7系列用JDK 8或JDK 11都能跑得很稳定，但SpringBoot 3.x系列强制要求JDK 17以上。你先确认项目的pom.xml里的spring-boot-starter-parent版本，再决定是装JDK 8还是JDK 17。如果项目是3.x，而你电脑上是JDK 8，Maven编译时就会报不支持版本错误。同一个电脑装多个JDK版本是可以的，IDEA里通过Project Structure切换即可。

Maven的配置重点有两个：一是本地仓库路径和阿里云镜像，否则依赖下载速度会让人崩溃；二是IDEA里要配置好Maven settings文件。建议在settings.xml里配置阿里云镜像：

xml复制<mirror>
    <id>aliyunmaven</id>
    <mirrorOf>central</mirrorOf>
    <name>阿里云公共仓库</name>
    <url>https://maven.aliyun.com/repository/public</url>
</mirror>

Node.js版本对Vue项目的构建也有影响。Vue CLI创建的老项目在Node 17+版本上构建时，偶尔会报OpenSSL错误，原因是webpack 4依赖的md4哈希算法在新版Node里默认不支持了。解决方案要么是降低Node版本，要么在package.json的scripts里配置set NODE_OPTIONS=--openssl-legacy-provider（Windows系统）。Vite构建的Vue3项目通常没有这个问题。

5.2 MySQL数据库初始化

考勤系统后端一般都会使用MySQL。本地建议安装MySQL 5.7或8.0版本，并通过Navicat或命令行执行SQL脚本。

执行SQL脚本前，先确认数据库账号密码和后端配置文件一致。打开后端项目src/main/resources目录下的application.yml：

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

这里有一个高频踩坑点：MySQL 8.0的驱动类是com.mysql.cj.jdbc.Driver，MySQL 5.7是com.mysql.jdbc.Driver。如果在pom里引入的是mysql-connector-java 8.x版本，驱动类必须用cj的，否则项目启动直接报ClassNotFoundException。serverTimezone=Asia/Shanghai也要保留，否则数据库和本地时区不一致会导致时间字段相差8小时。

5.3 后端启动与调试配套

后端启动前先把代码导入IDEA，重点确认两部分。

第一是检查Maven是否已经把依赖全部拉下来。如果pom.xml文件中有任何红色报错，先右键项目执行Maven Reload Project。依赖下载失败要优先检查网络和镜像配置。

第二是检查数据库连接配置无误后，直接运行启动类。看到SpringBoot启动日志里出现“Started Application in x.xx seconds”字样，就说明后端已经就绪。此时可以用接口文档工具先调一下登录接口，确认数据库里的种子账号能正常登录。

本地调试时建议开启热部署功能。SpringBoot项目在pom中引入spring-boot-devtools依赖后，IDEA中修改代码会自动重启服务，免去手动重启的繁琐。不过需要注意，热部署与调试模式同时使用可能会造成端口占用，这种情况下建议放弃部分自动重启，改为手动操作。

5.4 前端启动与接口联调配置

Vue前端启动流程相对标准：npm install安装依赖，npm run serve启动开发服务器。这里有一个细节值得留意，npm install的下载源如果慢，可以先配置淘宝镜像：

bash复制npm config set registry https://registry.npmmirror.com

前端能启动之后，最关键的配置是接口代理地址。开发环境下，Vue前端默认跑在8080端口，后端跑在8080端口。直接让前端请求后端会触发跨域，所以需要在vue.config.js里配置开发代理：

javascript复制module.exports = {
  devServer: {
    port: 8081,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
}

这样配置后，前端页面里请求/api开头的接口时，开发服务器会把请求转发到后端地址，浏览器的Network里看到的请求地址依然是前端地址，不会产生跨域问题。这也是目前Vue项目最主流的开发模式。项目部署时，再把打包后的dist目录放到Nginx里，并同样配置Nginx反向代理到后端服务。

5.5 运行过程中的常见异常速查

把我在跑这类项目时遇到的频率最高的报错整理成了一张表，如果你启动失败，可以照着这一条条排查：

这些坑几乎每个跑SpringBoot+Vue项目的人都会遇到至少两三个。提前把这些截图和排查过程记录下来，写进毕设的“系统测试与问题解决”章节，答辩时特别加分。

6. 答辩讲解重点与项目二次开发方向

6.1 答辩时如何把项目讲出层次感

很多同学答辩失败不是项目做得差，而是不会讲。拿到项目后在脑子里过一遍“讲故事的顺序”，通常按照这个路径：

从选题背景讲到痛点，再引出解决方案——为什么选考勤系统，因为课堂考勤管理繁琐且数据分散；为什么用SpringBoot+Vue，因为前后端分离便于维护扩展。接下来讲系统设计，包括总体架构、功能模块、数据库设计，核心是展示E-R图和数据表关系。然后进入亮点展示：把JWT鉴权、防重签到、请假状态机、Excel导出这几个功能点逐个讲清楚。最后的时间留给演示，演示时不要登录管理员直接看大而全的页面，而是按照场景演示——先以教师身份建课程、录考勤，再以学生身份查看缺勤记录，最后以管理员身份看统计报表，这样故事线更清晰。

提前准备几个可能被追问的问题：数据库索引为什么这么建？分页怎么实现？如果每秒有1万次签到请求怎么处理？第一个是索引覆盖问题，答联合索引和查询计划；第二个是MyBatis-Plus分页插件原理，答LIMIT和COUNT；第三个先答垂直扩展、Redis缓存、消息队列削峰，再承认当前项目未实现这些，但可以给出扩展方案。诚实加上思路，就是高分回答。

6.2 从毕设到可展示作品的功能扩展思路

这套考勤系统跑通之后，如果有多余的精力，我强烈建议再花一个周末做一个小扩展。不需要大动干戈，挑一个方向做精即可。

扩展方向一：接入MinIO对象存储。这个非常适合补充“画像上传”功能——学生注册或信息维护时可以上传头像，管理员上传课程封面。MinIO部署在企业内网作为私有对象存储非常常见，把这个能力集成到SpringBoot项目里，是简历上能写的加分项。

扩展方向二：使用ECharts做一个“课堂出勤热力图”。对教师账号开放一个可视化页面，横轴是第1周到第18周，纵轴是学生名单，单元格颜色越深表示缺勤越严重。一眼定位哪些学生哪些时段频繁缺勤，这功能实现难度不高，但展示效果好，尤其适合期末答辩现场演示。

扩展方向三：加入迟到规则配置化。为了取悦部分严格要求课堂纪律的老师，可以设计一个配置界面，允许每个老师自定义考勤规则，比如“迟到15分钟算缺勤”“每门课缺勤3次自动预警”。把规则参数存到一张表里，考勤判定逻辑从配置中读取，这就从“固定逻辑系统”升级成了“轻量规则引擎”，也是很好的论文研究方向。

6.3 我的个人实操心法与建议

最后聊几句实在话。做毕设最重要的是“主线清晰”，不要同时铺太多支线。如果是第一次接触前后端分离项目，先确保把“登录→查列表→做增删改→统计报表”这条最简单的主线完整跑通，再去考虑权限、导入导出、图表、消息通知这些分支。支线功能就算只做出来一个，也足够在答辩中当作亮点。

配套的SQL脚本和接口文档，在项目写完后务必从头到尾再过一遍。SQL脚本要用一个干净的数据库完整执行一遍，确保新环境下能一次通过；接口文档则要对着每一个接口重新调一次，避免论文里贴的示例和实际请求对不上。

动手前先看源码结构和表结构的关系，顺着“界面→前端API→后端Controller→Service→Mapper→数据库”这条链路把每个业务场景走一遍。这个步骤看似花时间，却能帮你快速建立起整个项目的全局认知，后期开发和答辩都会事半功倍。