Spring Boot+Vue企业考勤管理系统：前后端分离架构与全栈实战

简介本资源是一套基于Spring Boot后端与Vue前端的企业级考勤管理系统完整实现专为Java初学者及高校学生设计适用于课程设计、期末大作业与毕业设计等实践场景解决企业员工打卡、请假、审批、统计等核心考勤管理需求。压缩包共26630个文件涵盖14499个JavaScript逻辑文件、4754个JSON配置与数据文件、2741个TypeScript类型定义、143个Vue单文件组件及37个Java后端业务类辅以YML配置、SQL建表脚本、CSS/SCSS样式与Markdown文档结构清晰、模块解耦便于理解前后端分离架构与RESTful接口设计。资源包大小为53.24MB已有880人学习下载。用户可直接导入IDE与Vue CLI运行含完整数据库脚本与初始化数据小白亦可快速部署代码纯手写、注释规范、无冗余依赖具备高分项目典型特征——功能完整、界面简洁、权限分明、日志可查是掌握Java全栈开发流程的优质实操范例。1. 项目概述与核心价值分析拿到这个“基于SpringbootVue的企业考勤管理系统源码数据库95分以上大作业项目.zip”我先聊聊它到底是什么、能做什么、适合谁用。先说结论这是一套完整的前后端分离的Java Web项目技术栈是Spring Boot做后端接口服务、Vue做前端页面交互、MySQL存数据打包成一个可以直接导入运行、用于课程设计或毕业设计答辩的完整工程。你解压之后拿到的不是零散代码而是一个包含后端工程、前端工程、SQL初始化脚本、项目说明文档的全家桶。它能解决什么问题对在校学生来说最直接的价值就是“交作业”——而且是能拿高分那种。考勤管理系统是管理信息系统里非常经典的选题业务逻辑清晰、功能边界明确、技术点覆盖全面无论是做课程设计还是本科毕设都是评委老师眼中“既不难、又完整”的典型项目。但更重要的一点是这类项目的代码结构和技术选型是完全可以复用到其他管理类系统的——你把员工换成学生、考勤换成选课就是一个新项目。所以它不只是“交作业用的”更是你理解前后端分离开发、RESTful API设计、RBAC权限模型的最佳样板。我见过太多学生拿着找来的项目连数据库都导不进去就开始慌。这个项目之所以敢标“95分以上”核心不在于功能有多花哨而在于它把该有的东西都补齐了完整的数据库设计、规范的三层架构、清晰的接口定义、能跑通的前后端联调。这些都是答辩时老师最看重的东西。适合谁来参考第一类是计算机/软件工程专业的大三、大四学生正愁课设或毕设选题第二类是自学Java全栈、想找一个完整项目练手的初级开发者可以通过阅读和改造它来理解真实项目的运转逻辑第三类是时间紧张、需要快速搞定一个能演示、能讲解的项目的在职学生。不过我得先把丑话说在前面拿别人的项目交作业可以但答辩前一定要把代码读透、能讲清楚每一个表为什么这么设计、每一个接口的请求流程是什么否则老师一追问就露馅了。2. 系统整体架构与技术选型拆解2.1 为什么选Spring Boot Vue这套组合先说一个很多初学者没搞明白的问题为什么考勤管理系统要用前后端分离架构直接用一个Spring Boot模板引擎比如Thymeleaf把页面和后端揉在一起不行吗答案是能但拿不到95分。评分高的项目评委老师看重的往往不是业务多么复杂而是你是否采用了当前企业主流的技术方案。前后端分离是目前开发团队的实际工作模式——前端负责页面渲染和交互后端只输出JSON数据两边通过接口通信、并行开发。你把这种模式搬进课程设计本身就是加分项。再具体说Spring Boot。它解决的问题是“微服务时代快速构建独立应用”内嵌Tomcat、自动配置、起步依赖管理让你不需要手动配置一堆XML文件就能把服务跑起来。对于学生做课设来说Spring Boot几乎是零成本上手一个RestController注解就能暴露接口一个application.yml就能配好数据源写起来非常直观。Vue这边呢Vue 2或Vue 3的选项式API对新手极其友好。它不像React那样需要理解JSX和函数式组件的思维模型你只需要在template里写HTML、在script里定义data()和methods就能实现页面的数据绑定和交互。考勤管理这类系统的页面逻辑并不复杂——表格展示、表单弹窗、状态切换——Vue的指令系统和组件化开发恰好能把这些事做得干净利落。2.2 三层架构与模块边界划分整个系统的代码组织遵循经典的“Controller-Service-Mapper”三层架构这是企业级Java项目的标准范式也是答辩时老师最喜欢问的一个点。2.2.1 Controller层Controller层负责接收前端请求、参数校验、调用Service层能力、返回统一格式的响应体。写这一层的时候有个细节值得注意返回给前端的结构尽量统一比如一个Result类包含code、message、data三个字段。这样前端axios拦截器就可以统一处理错误码而不是每个接口各写一套返回格式联调的时候能少掉一半头发。2.2.2 Service层Service层是业务逻辑的核心位置。考勤系统的业务规则都在这里体现——比如“迟到判定”不是简单的时间比较而是要考虑弹性上班时间、加班调休抵消、外勤打卡特殊处理比如“请假审批”涉及多级审批流和状态机流转。这些逻辑如果写在Controller里代码会迅速腐化成一座屎山拆到Service层并明确每个方法的边界代码阅读性和可测试性都会好很多。2.2.3 Mapper层Mapper层是数据访问层与数据库表结构一一对应。这里有一个高频问题Mapper层到底用MyBatis还是JPA我的项目里选了MyBatis配合MyBatis-Plus增强工具原因是MyBatis让你对SQL有完全的控制力复杂报表查询写起来更顺手MyBatis-Plus则提供了开箱即用的CRUD方法让简单的增删改查不用重复造轮子。两个一结合写代码的速度和SQL可控性都有了。2.3 技术栈选型明细与版本对照层级技术选型核心作用前端框架Vue 2.6 Element UI页面搭建与组件库前端构建Vue CLI / npm工程化构建与依赖管理HTTP通信Axios前端发起HTTP请求后端框架Spring Boot 2.3.x核心服务框架持久层MyBatis-Plus 3.4.xORM与SQL增强数据库MySQL 5.7 / 8.0数据存储权限认证JWT Spring Security登录鉴权与接口保护项目管理Maven依赖管理与打包注意Spring Boot版本不用纠结是否最新。2.3.x是市面上教学资源最丰富、兼容性最稳定的版本线。如果选Spring Boot 3.x会牵涉到javax到jakarta的命名空间迁移很多网上的教程代码会报错学生阶段完全没必要踩这个坑。3. 核心功能模块与数据库设计精讲3.1 考勤系统的五个核心业务模块一个完整的考勤管理系统功能上至少要覆盖五个维度用户与权限、考勤记录、请假审批、统计报表、系统配置。我逐个拆开说。用户与权限模块这是系统的地基。用户表用户ID、用户名、密码、姓名、部门ID、职位、手机号、邮箱、入职日期、状态之外还要配角色表管理员、HR、部门经理、普通员工以及用户-角色关联表。这里采用的是经典的RBAC基于角色的访问控制模型——用户不直接绑定权限而是通过“用户-角色-权限”三级关联实现。这样新增一个用户时只需要给他分配角色而不需要逐项勾选菜单权限。考勤记录模块核心表是考勤记录表记录每一次打卡行为打卡类型上班/下班、打卡时间、打卡日期、考勤状态正常/迟到/早退/旷工/外勤。这个表要建索引因为后续统计报表会频繁按日期范围查询。生产环境里还要考虑补卡申请——员工忘打卡了怎么办需要额外设计一张补卡申请表走审批流程。请假审批模块考勤系统不能只有打卡还得有请假、加班、出差这些“非正常考勤”的场景。请假表记录请假类型事假/病假/年假/调休、开始时间、结束时间、请假天数、审批状态待审批/通过/驳回、审批意见。审批流的设计上最简单的方案是“员工提交 → 直属上级审批”复杂一点可以做多级审批链但课设做到单级就够了。统计报表模块这一块是很多项目的短板做好却是答辩的加分项。至少要有个人考勤月度汇总出勤天数、迟到次数、早退次数、请假天数、加班时长、部门考勤汇总、异常考勤明细导出。导出功能一般用EasyPoi或EasyExcel把数据写到Excel文件返回给前端下载很实用。系统管理模块包含部门管理树形结构支持多级部门、班次管理如白班9:00-18:00、夜班21:00-次日6:00、公告管理发布考勤相关的通知。班次管理容易被忽略但它其实是考勤规则的核心——系统判断员工是否迟到依据的就是这个员工所在部门绑定到班次的上下班时间。3.2 数据库表设计要点与建表SQL解读数据库设计是答辩时老师几乎必问的环节。我直接给出这套系统的核心建表思路你可以对照自己项目看有没有缺漏。员工表和用户表的关系很多人搞不清。我的做法是拆成两张表用户表管登录认证账号、密码、状态员工表管业务属性姓名、工号、部门、职位、入职时间。两表通过用户ID一对一关联。这样设计的好处是后续如果系统要加“客户”角色不需要把员工表里的字段挪来挪去。考勤记录表的SQL大致长这样CREATE TABLE attendance_record ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键, user_id bigint(20) NOT NULL COMMENT 用户ID, attendance_date date NOT NULL COMMENT 考勤日期, check_in_time datetime DEFAULT NULL COMMENT 上班打卡时间, check_out_time datetime DEFAULT NULL COMMENT 下班打卡时间, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1正常 2迟到 3早退 4旷工 5外勤, remark varchar(255) DEFAULT NULL COMMENT 备注, PRIMARY KEY (id), KEY idx_user_date (user_id, attendance_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT考勤记录表;这个设计里有几个细节值得说说。一是status用tinyint而不是varchar存储占用小、查询效率高对应的含义在代码里用枚举类维护二是联合索引idx_user_date因为日常查询几乎都是“查这个人在某段时间的考勤记录”走这个索引能大幅提速三是所有表都用InnoDB引擎支持事务和外键——比如员工归属部门如果部门删了但员工还在这个关联就会出问题InnoDB的事务机制能帮你兜底。请假申请表里的“审批状态”字段建议用整数0待审批/1通过/2驳回而不是直接存中文。原因有二一是数据库中英文字符的排序和比较效率更高二是后续如果要扩展状态比如“已撤回”加一个数字即可不需要改表结构。3.3 JWT认证与Spring Security权限控制考勤系统里不同类型的用户能做的事不一样普通员工只能看自己的考勤、提交请假部门经理能看到本部门下属的考勤汇总、审批下属的请假单HR和系统管理员拥有全部权限包括部门管理、班次管理和考勤规则配置。这背后就是Spring Security JWT在做支撑。JWTJSON Web Token的机制可以这样理解用户登录成功后后端生成一个包含用户ID、用户名、过期时间的签名字符串返回给前端前端把它存在localStorage里每次请求时放进HTTP头部的Authorization: Bearer token后端通过拦截器验证这个token的合法性和时效性就能知道请求方是谁、有没有权限。关键代码片段JWT工具类核心方法public String generateToken(Long userId, String username) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 86400000)) // 24小时有效期 .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }代码里这个86400000毫秒等于24小时是单日登录态的合理长度。实际开发中你可以把它做成配置项放在application.yml里方便修改。签名密钥SECRET_KEY必须妥善保管生产环境中一般通过环境变量注入而不是硬编码在代码里。4. 项目部署实操从解压到跑通全流程4.1 环境准备与版本匹配拿到源码包之后第一件事不是急着拖进IDE而是先把运行环境准备好。我按“前端 → 后端 → 数据库”的顺序给你列一份检查清单。后端环境JDK 1.8Spring Boot 2.3.x基于Java 8编译不要用17或21会有兼容问题Maven 3.6用于下载依赖和打包用IDEA自带的Maven也可以IDEA或Eclipse推荐IDEA对Spring Boot的支持好得多前端环境Node.js 14.x或16.xVue CLI 4或5要求Node 10以上但也不要装最新的Node 20可能报依赖兼容的错误npm或yarn用来安装Vue项目依赖数据库环境MySQL 5.7或8.0推荐5.7资源和稳定性最好Navicat或MySQL Workbench用于导入SQL脚本、查看数据注意版本问题是大作业项目跑不起来的头号原因。我遇到过一个学生后端代码没问题、前端代码没问题就是Node装了最新的20.x版本导致Vue项目npm install时报错node-sass编译失败花了整整一天排查。如果你也遇到类似问题换Node 16基本能解决。4.2 数据库初始化与配置打开sql目录下的初始化脚本里面通常会包含建库语句、建表语句、初始数据插入语句。用Navicat执行的时候我建议分三步走先手动创建数据库CREATE DATABASE attendance_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。这里注意字符集要明确指定为utf8mb4否则中文会乱码。选中刚创建的数据库再执行建表SQL脚本。执行初始数据脚本。验证是否成功的最快方式查询sys_user表看是否有一条admin/admin123的初始管理员账号。然后修改后端配置文件application.ymlspring: datasource: url: jdbc:mysql://localhost:3306/attendance_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.DriverserverTimezoneAsia/Shanghai必须加上否则MySQL 8.0默认的时区配置会导致数据库连接报错。useSSLfalse是因为本地开发不需要加密连接不加的话控制台会刷一堆SSL警告。4.3 后端工程启动步骤后端工程导入IDEA后等待Maven把依赖下载完。这个过程可能比较慢因为要拉上百个jar包耐心等。如果下载失败优先检查Maven的镜像源是不是默认的中央仓库——国内网络环境下建议在settings.xml里配置阿里云镜像mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url /mirror依赖加载完成后找到主类一般是AttendanceApplication.java右键以Java Application方式运行。看到类似这段日志说明启动成功Tomcat started on port(s): 8080 (http) with context path Started AttendanceApplication in 3.24 seconds后端默认跑在8080端口。如果想改成别的端口在application.yml里修改server.port即可。4.4 前端工程启动步骤前端工程目录一般长这样frontend/ ├── node_modules/ ├── public/ ├── src/ │ ├── api/ # 封装axios接口请求 │ ├── assets/ # 静态资源 │ ├── components/ # 通用组件 │ ├── router/ # 路由配置 │ ├── store/ # Vuex状态管理 │ ├── views/ # 页面组件 │ ├── App.vue │ └── main.js ├── package.json └── vue.config.js启动前先安装依赖npm install安装过程出现几个warning是正常的只要不是error就行。依赖装好后执行npm run serve等编译完成控制台会显示访问地址通常是http://localhost:8081。为什么前端不能用8080因为后端占了8080两个服务不能共用端口。前端默认端口可以在vue.config.js里通过devServer.port修改同时也建议配一下proxy代理把前端的/api请求转发到后端的8080端口完美规避跨域问题module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }4.5 前后端联调验证的五个检查点项目跑起来不代表就完事了我整理了一个联调自检清单按顺序验证一遍基本可以确认系统功能完整浏览器访问http://localhost:8081能正常看到登录页页面样式不塌陷。用admin/admin123账号登录能跳转到首页右上角显示“管理员”角色。打开浏览器开发者工具F12切到Network面板点击某个菜单观察接口请求返回code: 200且响应数据不为空。在“员工考勤”页面点“打卡上班”按钮数据库attendance_record表新增一条记录状态字段值为1正常。修改个人信息后刷新页面数据能持久化保留而不是刷新后变回原样。这五步都通过说明你的项目和数据库是联通、能正常工作的。如果某一步挂了优先从Network面板看是请求没发出去、还是后端报错、还是数据库查询失败——先定位问题在哪一层再逐个排查。5. 核心代码实现与业务逻辑剖析空谈架构没意思这一节我把考勤系统里最核心、也是最容易出bug的几个业务场景用代码级别的细节给你讲透。5.1 登录认证与用户信息获取登录接口是最基础也是最关键的接口。前后端分离模式下登录成功后后端要返回token以及用户的“信息头”——姓名、角色、头像这样前端才能根据角色动态渲染菜单和按钮。### 5.2 打卡签到与迟到自动判定 打卡接口的代码逻辑表面上是“插入一条考勤记录”实际处理时却要考虑三种情况 **当天第一次打卡 - 记为上班打卡** java PostMapping(/checkIn) public Result checkIn(RequestBody CheckInDTO dto) { // 获取当前登录用户 Long currentUserId SecurityUtils.getCurrentUserId(); // 查询用户绑定的考勤班次比如 09:00上班18:00下班 AttendanceRule rule attendanceRuleService.getRuleByUserId(currentUserId); // 获取今天是否已有打卡记录 LocalDate today LocalDate.now(); AttendanceRecord record attendanceRecordService.getTodayRecord(currentUserId, today); if (record null) { // 第一次打卡 - 创建记录判断是否迟到 record new AttendanceRecord(); record.setUserId(currentUserId); record.setAttendanceDate(today); record.setCheckInTime(new Date()); Date now new Date(); if (now.after(rule.getWorkStartTime())) { record.setStatus(2); // 迟到 } else { record.setStatus(1); // 正常 } attendanceRecordService.save(record); return Result.success(打卡成功); } return Result.error(今日已打过卡请勿重复操作); }第二次打卡 - 更新下班打卡时间else if (record.getCheckOutTime() null) { record.setCheckOutTime(new Date()); // 比对下班时间是否早退 if (new Date().before(rule.getWorkEndTime())) { // 如果已经有了迟到状态这里要注意不要覆盖掉 if (record.getStatus() ! 2) { record.setStatus(3); // 早退 } } attendanceRecordService.updateById(record); return Result.success(下班打卡成功); }实践心得这里有一个隐藏bug——如果员工上班迟到状态2下班又早退你会把状态覆盖成3导致“迟到早退”变成只有早退。正确做法是状态字段用位标志或再增加一个字段记录“是否迟到”。我的方案是增加late_flag和leave_early_flag两个布尔字段status只记录最终综合判定结果这样统计报表才能准确计算迟到次数和早退次数。重复打卡 - 拒绝并给提示逻辑见上面的else分支。5.3 请假审批流的状态机设计请假申请从提交到归档会经历多个状态待审批 → 通过/驳回。如果后续要加“撤回”功能就是待审批 → 已撤回。这是一个典型的状态机模型。我的实现思路是用一个status字段 一组状态流转校验public void approve(Long id, Integer status, String approvalComment) { LeaveRequest leave leaveRequestService.getById(id); // 校验当前状态是否允许执行此操作 if (leave.getStatus() ! 0) { throw new BusinessException(该申请已被处理请勿重复操作); } // 审批人必须是指定的审批人即直属上级 if (!leave.getApproverId().equals(SecurityUtils.getCurrentUserId())) { throw new BusinessException(您不是该申请的审批人); } leave.setStatus(status); // 1通过 2驳回 leave.setApprovalComment(approvalComment); leave.setApprovalTime(new Date()); leaveRequestService.updateById(leave); }这段代码里最关键的是“幂等性校验”——如果前端因为网络超时重发了审批请求后端必须保证第二次操作不会把第一次的结果覆盖掉或产生脏数据。这是企业级开发里非常看重的一个能力也是一般课设项目中不会被注意但答辩时提升档次的地方。5.4 报表统计的SQL编写技巧统计报表是整个系统里“含金量”最高的功能因为很多课设项目能做到增删改查但做不好聚合查询。月度考勤汇总的核心SQL如下SELECT user_id, DATE_FORMAT(attendance_date, %Y-%m) AS month, COUNT(*) AS total_days, SUM(CASE WHEN status 1 THEN 1 ELSE 0 END) AS normal_days, SUM(CASE WHEN status 2 THEN 1 ELSE 0 END) AS late_count, SUM(CASE WHEN status 3 THEN 1 ELSE 0 END) AS leave_early_count, SUM(CASE WHEN status 4 THEN 1 ELSE 0 END) AS absent_count FROM attendance_record WHERE attendance_date BETWEEN #{startDate} AND #{endDate} GROUP BY user_id, DATE_FORMAT(attendance_date, %Y-%m)这里用了CASE WHEN配合SUM做条件计数是SQL聚合查询里最常用的手法比“先把数据全查出来再在Java里循环统计”高效得多。报表模块建议配合EasyExcel做导出Excel的标题行和字段映射用注解就能搞定几分钟就能写完一个导出接口。6. 项目答辩与二次开发经验指南6.1 答辩时老师最爱问的问题清单经历过无数次答辩现场的洗礼我帮你梳理一下老师看到考勤系统时最可能追问的问题提前准备好答案答辩就有了主心骨问题应答思路为什么考勤记录表要建联合索引因为查询条件通常同时包含用户ID和日期范围联合索引可以一次命中避免全表扫描用户的密码是怎么加密存储的使用Spring Security的BCryptPasswordEncoder每次加密结果不同即使两次密码相同、密文也不同前后端分离的认证方式是什么JWT无状态认证服务端不需要存Session客户端请求带着Token即可如果领导修改了排班规则对已有考勤记录有影响吗规则修改只影响之后新生成的考勤判断历史记录已固化在库中不会回算系统如何应对大量用户同时打卡数据库层面靠索引和唯一键用户日期防重复代码层面做并发校验比如用数据库乐观锁或分布式锁每一个问题回答时都要往“业务规则”上引而不是只讲“我用了一个注解”。比如问密码加密你说“因为用户密码是敏感数据数据库泄露时明文密码会连累用户在别的网站的账号所以用BCrypt这种不可逆加密来存储”就比“我用Spring Security自带的功能”强得多。6.2 从课设到简历项目的改造建议源码拿到手之后你不应该做的是“原封不动传到GitHub就开始投简历”。这种项目你写在简历里面试官一搜代码仓库就能发现是同款——而且人人都写过考勤系统没有差异化就没有说服力。我的改造建议是给项目添加一个“特色功能点”这个点最好是班次管理之外的、有技术含量的能力引入Redis缓存将用户的基本信息和权限信息缓存到Redis减少数据库压力。面试时聊“为什么用缓存、缓存失效怎么处理、缓存和数据库一致性怎么保证”这些都是后端面试的高频考点。增加WebSocket实时通知员工提交请假后审批人页面实时弹出有新审批待处理的提醒。这比传统的“刷新页面才看到”体验好很多而且WebSocket是现在企业级开发的必备知识点。Excel批量导入导出增强支持按部门、按月一键导出考勤报表并加入异常数据高亮显示。这既实用又有技术细节。加入钉钉/企微对接的模拟模块模拟考勤机打卡数据同步到系统的接口设计中用消息队列RabbitMQ做异步解耦。哪怕只做完第一个功能你在面试时的谈资都会不一样——因为你不再只是“用增删改查完成需求”而是开始思考“怎么把系统做得更快、更稳、体验更好”这才是程序员的核心竞争力。6.3 数据库备份与安全配置最后说一个很多学生容易忽略的问题项目交付时只交一份SQL脚本但答辩当天如果数据库数据被改坏了现场演示就尴尬了。我建议你在项目里附带两个脚本init.sql初始化脚本包含建库建表和基础数据和sample_data.sql演示数据脚本包含几十条考勤记录、几条请假单方便演示统计报表时有内容可看。答辩前半小时在备用电脑上把环境重新搭一遍确保即使主电脑出问题也能在备用环境上完成演示。后端配置文件里数据库密码是明文存在的本地开发可以理解但如果要把代码传到GitHub上最好使用application-prod.yml单独存放生产配置并在.gitignore中排除它。你的提交前检查就多一条不要提交含有真实密码的文件。7. 常见问题排查与避坑实录7.1 环境与启动问题速查表这里把我在陪学生们跑这个项目时遇到的Top 10高频问题整理成一个速查表。你对照症状找解法能省下大半天排查时间错误现象根本原因解决办法IDEA导入后Maven一直加载中首次下载依赖较多/网络慢配置阿里云镜像检查Maven是否使用JDK1.8启动时报Failed to configure a DataSource没有配置数据源或数据库没启动检查application.yml的url、账号、密码确认MySQL服务已启动登录后接口返回token过期系统时间不同步或token有效期太短检查本机时间在JWT工具类中调长过期时间如7天浏览器控制台报跨域错误前端页面和后端接口不在同源使用vue.config.js里的proxy配置或写一个CorsConfig配置类放行中文数据入库后乱码数据库字符集不是utf8mb4建库语句显式指定CHARACTER SET utf8mb4npm install报node-sass错误Node.js版本过高改用node 14或16版本或者把node-sass换成sass前端页面白屏但无报错前端路由配置中路径少了/检查router/index.js的路由路径以及与后端接口路径的匹配关系8080端口被占用导致启动失败其他进程占用了端口修改server.port为8082等或找出并杀掉占用进程打卡后数据库查询不到记录事务未提交或主键冲突检查Service层是否加了Transactional查看是否有唯一索引冲突导出Excel报java.lang.NoClassDefFoundError缺少EasyPoi相关依赖在pom.xml中检查poi和easypoi的依赖是否有冲突统一用4.1.2版本7.2 踩坑实录三个案例复盘除了速查表我再分享三个具体的“翻车现场”这些案例都是真实发生过的它们能帮你更早发现潜在问题。案例一登录接口偶发超时。一个同学的考勤系统刚上线测试时前端点击“登录”后偶尔要等5秒才跳转有时直接超时。排查发现密码校验用的是BCryptPasswordEncoder.matches()而BCrypt算法本身为了抗暴力破解,设计上就是故意慢的——一次校验需要几十到几百毫秒。如果密码库中用户很多每次登录都同步校验就会拖慢。解决方案是在用户表增加password_salt字段并缓存登录成功的token或者升级为“预校验异步校验”的方式。这个案例的教训是安全措施和环境复杂度会引入新的性能瓶颈你要能感知到它们的存在。案例二审批流出现“幽灵审批”。同一张请假单员工在提交后刷新了页面然后再点了一次“提交”结果数据库中出现了两条请假记录审批人那边收到了两个待办。这就是我前面提到的幂等性问题。事后排查表单提交接口在Controller里加了Valid参数校验但没有做防重处理。解决方案是在“提交”接口里加一个基于用户ID和时间的防重逻辑——比如一分钟内相同用户、相同请假类型的重复请求直接拦截。这个bug一般不会在正常操作中暴露但一旦出现会给人“系统不可靠”的糟糕印象。案例三统计报表数字对不上。HR反应月度考勤汇总表里“正常天数”比实际打卡天数多。排查后发现问题出在时区上后端服务器设置的是UTC时区每周日凌晨的定时任务执行时LocalDate.now()得到的日期比北京时间晚8小时导致12月1日凌晨0点到8点的打卡记录被算到了11月30日。这件事让我第一次意识到凡是涉及“按天统计”的功能时区问题就是绕不过去的坎。解决办法是统一在数据库连接字符串中指定serverTimezoneAsia/Shanghai并在Java代码中统一使用ZoneId.of(Asia/Shanghai)获取当前日期。7.3 最后的调试小贴士最后分享几个我平时调试Spring Boot Vue项目特别顺手的小技巧能让你开发效率翻倍开启DevTools热部署。在pom.xml中加入spring-boot-devtools依赖后端代码修改后自动重启不用手动编译再启动省下大量等待时间。前端用Vue Devtools插件调试。这是一款浏览器扩展可以在页面上实时查看Vue组件的data和computed值排查数据绑定问题比瞎猜快得多。Postman或Apifox管理接口调试。把项目所有接口按照分类录入不仅方便自己调试答辩时还能展示“我平时是这么做接口测试的”——在老师心里这代表你具备工程化思维。数据库客户端用Navicat的模型功能。把表结构可视化生成ER模型实体关系图答辩PPT里贴一张ER图直接提升专业度。我的个人感受是这个考勤管理项目拿到手比起“能跑”更重要的是“能讲”。你在这个项目上投入时间越多从表结构设计到权限模型、从打卡判定到报表统计每一个环节都能讲出“为什么这么做”那么无论用于答辩、求职还是练手它都会成为你成长路上很扎实的一个脚印。如果你在部署或改造过程中遇到任何一处卡壳回头对着这篇笔记里的指向排查大概率都能找到解决方案。本文还有配套的精品资源点击获取