企业官网建设流程全解析

简介：本资源是一套完整的本科毕业设计项目，面向计算机专业学生及Java全栈初学者，聚焦企业级日常考勤管理场景，解决传统人工考勤效率低、数据难追溯、统计不及时等痛点。压缩包共414个文件，含98个SpringBoot后端Java核心代码、40个Vue前端组件（含BreadCrumbs、IndexAsideStatic等典型布局与业务模块）、18个XML配置与SQL脚本、17张JPG/PNG界面截图及2个MP4系统演示视频，整体大小25.67MB，结构清晰、模块分离明确。已有208人学习下载，资源提供开题报告、完整毕业论文（含需求分析、系统设计、测试用例）、可直接运行的MySQL数据库脚本（含初始化数据）以及三套批处理脚本（install/run/build），覆盖从环境搭建、功能验证到答辩材料准备的全流程，特别适合毕设快速落地与技术复现。 每年到毕业季，总有一批学弟学妹跑来问我：“学长，想做个人事考勤系统，到底怎么下手？”说实话，考勤系统这个题目在计算机毕业设计里属于经典中的经典——规模适中、业务闭环完整、技术栈主流，用来展示三年的学习成果刚刚好。但经典归经典，真正动手做起来，既要啃下SpringBoot后端接口，又要搞定Vue前端页面，还得把MySQL表结构设计得经得起推敲，最后论文、演示视频、答辩PPT一圈下来，工作量也不小。

这篇内容把我自己做考勤系统的完整思路整理出来，从技术选型到数据库设计，从后端接口实现到前端页面开发，再到论文写作和演示视频录制，整个过程一条线讲清楚。如果你也正准备拿这个题目做毕业设计，或者单纯想了解一个标准的前后端分离项目是怎么落地的，这篇文章可以直接当参考。

1. 考勤系统毕设的整体设计思路与技术选型

1.1 为什么选择SpringBoot + Vue + MySQL这套组合

先聊技术选型。2025年了，在Java方向做毕设，SpringBoot已经成了事实标准。它的好处不用多说——配置简化、生态成熟、社区资料多，遇到问题搜一圈基本能解决。相比传统的SSM框架，SpringBoot把大量样板配置收进了自动装配机制里，一个注解加几行配置文件就能跑起来，这正好匹配毕设项目“快速出一版可用系统”的节奏。

前端这块Vue依然是主流选择。Vue的学习曲线相对平缓：模板语法直观、双向绑定让表单操作变得简单、组件化开发方便把页面拆成可复用的模块。对于没有太多前端基础的同学来说，Vue + Element UI这套组合上手很快，Element UI直接把表格、表单、弹窗、日期选择器这些考勤系统需要的组件都准备好了，你要做的事情主要是把它们拼装起来。

MySQL在数据库选型上没什么悬念。轻量、免费、跨平台，不管是本地开发还是部署演示都很方便。考勤系统的数据模型不算复杂：用户表、打卡记录表、请假表、加班表，加上部门表，五张核心表就能把业务撑起来。

这套技术栈的组合还有个实际优势：参考资料极其丰富。SpringBoot、Vue、MySQL这三个词拿出来单独搜，资料铺天盖地；组合起来做考勤系统的教程也很多。遇到问题能找到参考，这点对毕设来说太重要了。

1.2 考勤系统的核心需求拆解

在动手写代码之前，先把需求理清楚。一个能过答辩的考勤系统，至少得覆盖以下业务环节：

员工端：

• 上下班打卡，记录打卡时间
• 查看自己的考勤记录，按月份筛选
• 请假申请，提交请假时间段和事由
• 加班申请，提交加班时间段
• 查看自己的考勤统计（出勤天数、迟到次数、请假天数等）

管理端：

• 员工管理：新增员工、编辑信息、禁用账号
• 部门管理：维护部门信息
• 考勤记录管理：查看所有员工考勤记录，支持补卡修正
• 请假审批：通过或驳回请假申请
• 加班审批：通过或驳回加班申请
• 考勤报表：按部门、按月统计出勤情况

把需求拆出来之后，整个系统的轮廓就清晰了。前后端分离的架构下，后端提供RESTful API，前端通过HTTP请求调用接口，数据存在MySQL里，这就是一个完整的全栈闭环。

1.3 项目结构和功能模块规划

基于上面的需求分析，项目结构可以分成这样：

后端采用经典的分层架构——Controller层接收前端请求，Service层处理业务逻辑，Mapper层（使用MyBatis-Plus）操作数据库，Entity层定义数据实体。这样的分层结构在答辩时也很好解释，评审老师一听就知道你有工程化思维。

功能模块规划上，我按照角色来划分：认证模块负责登录和权限校验，用户模块负责员工和管理员的管理，考勤模块负责打卡和记录查询，审批模块负责请假和加班审批，报表模块负责数据统计。每个模块的职责单一，开发和测试时可以单独推进，最后再整合联调。

前端这边，路由结构按功能划分：登录页、员工端首页、打卡页、考勤记录页、请假页、加班页、个人统计页；后台管理页面有用户管理、部门管理、考勤管理、请假审批、加班审批、考勤报表。后台的页面用Vue Router做权限控制，管理员和普通员工看到的路由不一样。

2. 数据库设计与核心表结构实现

2.1 数据库表结构设计思路

考勤系统的表结构设计直接决定了后面代码的复杂程度，这块值得花时间认真做。我采用的方案是五张核心表加两张关联表。表结构如下：

用户表sys_user

• id 主键自增
• username 用户名，唯一索引
• password 密码，BCrypt加密存储
• real_name 真实姓名
• phone 手机号
• dept_id 所属部门ID
• role 角色（0=员工，1=管理员）
• status 状态（1=正常，0=禁用）
• create_time 创建时间

部门表sys_dept

• id 主键
• dept_name 部门名称
• leader 负责人
• create_time

考勤记录表attendance_record

• id 主键
• user_id 用户ID
• work_date 上班日期
• check_in_time 上班打卡时间
• check_out_time 下班打卡时间
• status 考勤状态（0=正常，1=迟到，2=早退，3=缺卡，4=请假，5=加班）
• source 记录来源（0=自动生成，1=手动打卡）
• remark 备注

请假审批表leave_request

• id 主键
• user_id 申请人ID
• start_time 请假开始时间
• end_time 请假结束时间
• leave_type 请假类型（病假、事假、年假）
• reason 请假事由
• status 审批状态（0=待审批，1=已通过，2=已驳回）
• approver_id 审批人ID
• approve_remark 审批意见

加班审批表overtime_request

• id 主键
• user_id 申请人ID
• start_time 加班开始时间
• end_time 加班结束时间
• reason 加班事由
• status 审批状态
• approver_id 审批人ID
• approve_remark 审批意见

2.2 核心字段设计背后的考量

表结构里有一些字段的设计，是踩过坑之后才想明白的，这里重点说一下。

第一点是考勤记录的status字段。很多初版设计完全没有状态字段，直接通过对比打卡时间和规定上班时间来判断迟到、早退。这种方案的弊端在于：系统无法区分“迟到”和“请假半天”这两种情况。举个例子，员工上午请假，下午才来上班，打卡时间超出上班时间，如果你只按打卡时间判断，这个人就会被记为迟到，这明显不合理。加入status字段之后，请假审批通过时就可以把当天的考勤状态直接改为“请假”，不会被误判。等到月底统计时，就能得出相对准确的报表。

第二点是打卡记录表的日期字段单独用work_date，而不是直接用“打卡时间”里的日期来提取。刚开始我觉得直接截取打卡时间里的日期就行，后来发现这样需要在SQL里做日期函数处理，遇到时区问题还可能出错。单独维护一个work_date字段，在插入记录时明确写入，查询和统计都方便很多，索引也能用上。

第三点是用户表的dept_id，在员工和部门之间建立外键关联。虽然在真实项目中一般不推荐物理外键，但在毕设场景下，使用逻辑外键加Mapper层联查就足够了。答辩时如果被问到“为什么不用物理外键”，就回答“为了保证数据灵活性，在代码层做逻辑关联”，这也是业界主流的做法。

2.3 初始化数据与SQL脚本

数据库表建好之后，提前往系统里塞几类数据，方便开发和演示。比如部门表里加上“技术部”“人事部”“财务部”，用户表里加一个管理员账号和几个员工账号，员工账号的密码统一用BCrypt加密。数据库初始化脚本放在项目根目录下，论文里附录也放一份，评审老师看数据库设计时能直接打开看。

这里有个建议：初始化数据量不要太大，用户表放5-8个员工就够演示了，考勤记录可以写一个简单的SQL语句批量生成前两个月的数据，方便演示按月查询和统计功能。如果真的想体现工作态度，可以写个Java单元测试类，用循环插入数据，这样在答辩时还能展示一下“测试驱动开发”的思路。

3. SpringBoot后端核心功能实现

3.1 项目基础配置与依赖管理

后端项目我用SpringBoot 2.7系列 + JDK 1.8 + MyBatis-Plus + MySQL 5.7组合。这里要特别提醒：SpringBoot版本不要盲选最新版，2.7.x是我实测下来最稳的。选3.x的话，JDK要求17起步，而且许多第三方依赖的兼容性不如2.7，对毕设来说没必要给自己挖坑。

pom.xml核心依赖给大家一个参考：

<dependencies> <!-- SpringBoot Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis-Plus --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.2</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <!-- Lombok --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- JWT --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <!-- Hutool工具类 --> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.15</version> </dependency> </dependencies>

MyBatis-Plus在这个项目里体验很好，它把单表操作的CRUD都封装好了，BaseMapper自带增删改查接口，省去了大量手写SQL的重复劳动。多表关联查询的场景再用注解或XML手写SQL，既保留了效率又不失灵活性。

3.2 用户认证与权限控制实现

考勤系统的权限比较简单，就是管理员和普通员工两种角色。我用JWT + 拦截器的方式来做，核心流程是：

用户登录时，后端校验用户名和密码，密码使用BCrypt匹配。验证通过后生成一个JWT Token，Token里封装用户ID、用户名、角色信息，有效时长设为12小时。前端拿到Token后存在localStorage里，后续每次请求在请求头加上Authorization: Bearer xxx，后端写了一个拦截器统一解析Token，如果Token合法就把用户信息放到请求上下文中，供各个接口使用。

@Component public class JwtInterceptor implements HandlerInterceptor { @Autowired private JwtUtil jwtUtil; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口 if (request.getRequestURI().contains("/auth/login")) { return true; } String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); if (jwtUtil.isValid(token)) { return true; } } response.setStatus(401); return false; } }

这个拦截器再配合一个管理端接口的角色校验注解，就能覆盖考勤系统的权限控制需求了。注意拦截器放行路径务必要处理准确，Swagger文档路径、登录接口这些都要放行，否则前端联调时会遇到莫名其妙的401。

3.3 打卡接口的设计与实现

打卡是整个考勤系统业务逻辑最核心的部分。我的打卡逻辑是这样设计的：

上班打卡时，后端获取当前时间和用户ID，先判断今天是否已打卡，如果已打过则返回“请勿重复打卡”。没有打过就插入一条考勤记录，工作日期为今天，上班打卡时间为当前时间，同时根据打卡时间判断状态：在规定的上班时间之前的，初始状态为“正常”；晚于上班时间但处于宽限期内（比如9:00上班，9:15前）记为状态“迟到”，超过宽限期同样算迟到，但备注里会记录具体迟到时长。

这里我特意做了一个宽限期的设计。真实企业场景中，员工偶尔早上堵车，延迟几分钟打卡很正常。设计一个15分钟的缓冲期，避免了因为时间太死导致员工一个月迟到记录特别多的情况。在答辩时，这个设计可以作为一个业务思考的亮点来展示。

下班打卡的逻辑类似，更新当天记录的下班时间，早退判断则是对比规定下班时间和实际打卡时间。

3.4 考勤统计与报表的SQL优化

考勤统计功能涉及按月聚合数据，初期直接用Mapper查询大量数据在Java里做分组统计，在数据量不大的时候没问题，但数据量大了之后性能会明显下降。后来改成在SQL层面使用GROUP BY做聚合，性能提升了很多。

SELECT user_id, SUM(CASE WHEN status = 0 THEN 1 ELSE 0 END) AS normal_days, SUM(CASE WHEN status = 1 THEN 1 ELSE 0 END) AS late_days, SUM(CASE WHEN status = 2 THEN 1 ELSE 0 END) AS early_days, SUM(CASE WHEN status = 3 THEN 1 ELSE 0 END) AS miss_days, SUM(CASE WHEN status = 4 THEN 1 ELSE 0 END) AS leave_days, COUNT(*) AS total_days FROM attendance_record WHERE work_date BETWEEN #{startDate} AND #{endDate} GROUP BY user_id

这串SQL把五类考勤状态用条件聚合一次查出来，后端只要封装结果就行。实际测试下来，几万条记录的月汇总查询，毫秒级返回，展示起来很流畅。

3.5 定时任务自动生成考勤记录

系统里还有一块逻辑——每天凌晨自动为当前在职员工生成当天的考勤记录，状态默认为“缺卡”。为什么要这么做？因为如果员工一整天都没有打卡，数据库里就没记录，那月底统计时“缺卡”的人就查不出来。用定时任务每天生成一条空记录，后面如果员工补打卡或请假，再更新状态，这样每天的考勤记录都是连续的。

SpringBoot里用定时任务非常简单，在启动类上加上@EnableScheduling注解，然后写一个Service方法打上@Scheduled(cron = "0 0 0 * * ?")就搞定了。

4. Vue前端页面开发与交互实现

4.1 前端工程化和开发环境

前端项目用Vue CLI脚手架搭建，Vue 2.7版本，配合Element UI 2.15。之所以没有上Vue 3 + Element Plus，是因为Vue 3的中文资料相对更新，且部分Element Plus组件在毕业设计阶段还遇到过一些资料不匹配的情况。Vue 2.7虽然版本偏老，但资料稳定、坑都被人踩过，对毕设来说足够了。

前端项目结构我这样组织：

src/ ├── api/ # 接口请求封装 ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── router/ # 路由配置 ├── store/ # Vuex状态管理 ├── utils/ # 工具函数 ├── views/ │ ├── admin/ # 后台管理页面 │ └── employee/ # 员工端页面 ├── App.vue └── main.js

4.2 Axios拦截器与Token管理

前后端分离项目的核心交互就是HTTP请求，Axios封装得不好，后面联调会出现一堆代码重复的问题。我在utils/request.js里统一创建了一个Axios实例，配置了baseURL、请求超时时间，然后添加了请求拦截器和响应拦截器。

请求拦截器负责把本地存储的Token取出并添加到请求头。响应拦截器里统一处理HTTP错误码：401跳转登录页，500弹出错误提示。业务层的状态码在响应数据里单独定义，code为200表示成功，其他code弹出对应的业务提示信息。

import axios from 'axios' import { Message } from 'element-ui' 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 => { const res = response.data if (res.code === 401) { localStorage.removeItem('token') router.push('/login') return Promise.reject(new Error('登录过期')) } if (res.code !== 200) { Message.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res }, error => { Message.error(error.message) return Promise.reject(error) } ) export default request

这套封装的收益是：页面中调用接口只需要关注业务逻辑，不需要每次重复写错误处理。联调阶段的开发效率能提升不少，代码也干净。

4.3 员工端核心页面实现

员工端页面不多但都挺有代表性。登录页用了Element UI的卡片布局，表单验证加上用户名密码必填校验。打卡页是最有仪式感的页面，上面展示当前时间（用JavaScript的setInterval每秒更新），下面两个大按钮——上班打卡和下班打卡，打卡成功/失败都通过Message提示。打卡状态卡片展示今天的打卡时间和考勤状态。

考勤记录页用el-table展示考勤列表，顶部提供月份选择器，选择后调后端接口获取对应月份的记录。列表的每一行展示了日期、上班时间、下班时间、状态标签。状态字段用el-tag展示，不同颜色区分：绿色是“正常”、橙色是“迟到”、灰色是“缺卡”等。

请假页用el-form实现，表单里有请假开始时间、结束时间、请假类型、请假事由，时间选择器用的是el-date-picker的datetimerange模式。提交后跳转到“我的申请”列表页，能看到审批状态是“待审批”“已通过”还是“已驳回”。

4.4 管理端页面与权限路由

管理端的页面在路由配置上用Vue Router的beforeEach钩子做权限判断。用户登录后返回的userInfo里带角色字段，前端把角色存到Vuex里，路由跳转时检查目标路由的meta信息里要求的角色，不匹配就重定向到首页。

管理端几个页面的实现：

用户管理页：el-table展示用户列表，包含用户名、姓名、部门、角色、状态。操作列提供“编辑”“启用/禁用”按钮。新增和编辑用el-dialog里嵌el-form实现。部门选择器用el-select，选项数据从部门表拉取。

考勤管理页：默认展示当前所有员工的当日考勤记录，可以进行补卡操作——管理员把员工的上班或下班时间修正为指定时间。这是员工考勤管理场景里很实际的功能，万一员工因为外出办事忘打卡，管理员可以手动修正数据。这个功能的实现是调一个后端的修正打卡接口，更新对应记录的时间字段。

请假审批页：展示所有待审批的请假列表，管理员点开详情弹窗，看到申请人的请假时间和事由，然后可以选择“通过”或“驳回”，驳回时必须填写审批意见。

考勤报表页：用一个echarts柱状图展示各部门近一个月的出勤率，下方用el-table展示每个员工的出勤汇总（应出勤、实出勤、迟到、早退、缺卡次数等）。这个页面视觉效果最好，演示视频里重点展示这个页面，效果非常加分。

4.5 前端踩过的一些坑

前端开发过程中有一些坑，基本是新手必踩的，提前说一下避免重复折腾。

Vue 2的响应式系统无法检测到通过数组下标直接赋值的变化。在考勤记录页做批量操作时，如果直接改this.tableData[0].status = 1，页面有时候不会更新。正确的做法是使用this.$set(this.tableData[0], 'status', 1)。

路由懒加载的坑：在router配置里使用动态import后，排查页面加载异常时要先确认是不是路由配置写错了路径。如果路径配置正确却还是报错，就看下开发服务器控制台的编译报错信息。

Axios的baseURL要和vue.config.js里的devServer.proxy配置对应起来。开发环境下前端的请求通过WebpackDevServer代理转发到后端服务地址，这样解决跨域问题，生产环境则把前端打包后的dist目录放到Nginx里，配置反向代理到Java服务。

5. 毕业设计论文与开题报告写作指南

5.1 开题报告的写作框架

开题报告是拉开毕业设计工作量的第一步。考勤系统的开题报告我建议按照这个框架来写：

课题背景和意义部分，要讲清楚考勤管理在现代企业管理中的重要性，从传统手工登记考勤的低效率切入，引出信息化考勤系统的必要性。技术可行性分析部分，要说明SpringBoot的生态成熟度和个人掌握程度、Vue的组件化开发优势、MySQL的稳定性和易用性，同时表示数据库设计符合第三范式，数据完整性有保障。

需求分析部分，可以在开题报告里先列一个大致的功能模块清单，详细的用例图放到毕业论文里。研究内容与计划部分，按“需求分析→数据库设计→后端开发→前端开发→系统测试→论文撰写”来排列时间节点。

5.2 毕业论文的章节架构与内容分配

论文结构我采用的是比较标准的毕业设计论文结构。第三章需求分析要画出系统的用例图、功能模块图和数据流图，这些图如果不用专业绘图工具，用visio或processon画都行，关键是图要清晰、要素要完整。

第四章总体设计重点讲系统架构和数据库设计。架构图画出浏览层、应用层、数据层的三层结构，数据库设计放E-R图和核心表结构说明。这一章节内容是评审老师重点关心的，表结构里的每个字段都要有明确的注释说明。

第五章详细设计是论文里最长的章节，按功能模块划分小节，每个小节写功能描述、核心代码片段和运行效果截图。代码不要整段贴太多，贴真正核心的十几行就够，比如JWT拦截器逻辑、打卡接口的业务判断逻辑。效果截图必须是真实运行画面，保证清晰度。

第六章系统测试要分功能测试和性能测试两部分。功能测试写测试用例表格，包含测试编号、测试项、操作步骤、预期结果、实际结果、是否通过。性能测试可以简单写一下接口响应时间的测试结果，比如考勤统计接口在1000条测试数据下的查询耗时为XX毫秒，这些数据自己用Postman或JMeter测一下就能拿到。

5.3 论文写作的几个增分技巧

第一个技巧是引用业界规范。在写作过程中引用《软件开发规范》等行业标准，哪怕只是简单提一句“本系统遵循了软件工程的基本开发流程”，论文规范性和专业性都会提升不少。

第二个技巧是不要回避系统不足。在总结章节里写出系统的局限性和改进方向，比如“目前暂未实现人脸识别打卡，后续可以引入面部识别技术提升打卡的防作弊能力”，这比说自己系统完美无缺更加可信，还能展示你对领域发展的思考。

第三个技巧是用图表说话。需求分析阶段的用例图、流程图，设计阶段的架构图、E-R图，测试阶段的用例表格，图表至少要有8到10张。图文并茂的论文在观感和评分上都占优势。

6. 演示视频录制与答辩准备要点

6.1 演示视频的脚本设计与录制流程

演示视频在毕业设计交付物中的重要性容易被低估。有些同学代码实现了80分，视频演示草草录制，最终效果大打折扣。事实上，很多学校评审老师看视频的时间比看代码多，一个制作精良的演示视频能有效提升整体印象。

我录视频前先写脚本。整个演示流程是这样设计的：先说项目介绍（5秒背景 + 技术栈说明），然后展示系统登录页，输入管理员账号密码登录，接着从管理端开始演示，依次展示用户管理、部门管理、考勤管理、请假审批、考勤报表。然后退出登录，切换到员工账号登录，展示员工端的打卡页面、考勤记录、请假申请、个人统计。最后用20秒做一个系统总结和代码结构展示。

演示每个功能模块时，先说明该模块的功能定位，再实际操作演示流程。比如演示考勤报表时，先说“考勤报表模块用于按部门、按月份统计员工的出勤情况”，然后切换月份选项，用鼠标指出来各项统计数据的含义，让评审老师能清楚看到每个模块的工作流程和效果。

录屏用的OBS Studio，免费且支持1080p分辨率录制。分辨率设置成1920x1080，帧率30fps就可以了，录制过程中确保没有外部通知弹窗打扰。背景音乐建议不加，如果一定要加，音量调到几乎听不见的程度，不要影响讲解声音。

6.2 答辩常见问题与应答思路

答辩前把常见的提问准备好，到了现场就不慌了。这里把考勤系统最容易被问到的几个问题整理一下：

“为什么选择SpringBoot而不是其他框架？”

答题思路：SpringBoot在Java EE领域已经成为主流，它简化了传统Spring开发的XML配置，内嵌Tomcat使得部署更简单，同时社区生态完善，与MyBatis、Vue等技术都能很好地集成。在开发效率、部署便捷性、社区支持上都有明显优势。

“考勤状态是怎么判断的？”

答题思路：后端在接收到打卡请求后，会用当前时间与预先设置的上/下班时间进行比较。正常上班时间之前打卡是“正常状态”；上班时间之后15分钟宽限期内打卡记为“迟到”；没有打卡就是“缺卡”；请假审批通过则状态为“请假”。下班时间前打卡且时间差大于30分钟记为“早退”。

“如果员工在9点05分打卡，怎么判断他是否迟到？”

答题思路：以系统设置的打卡时间为准，比如上班时间是9点，加15分钟宽限期就是9点15分前。9点05分在宽限期以内，如果按严格模式这个时间算迟到，但考虑到企业管理的人性化，默认情况9点至9点15分打卡记录为“迟到”但备注“宽限期内”，也可以根据企业需求关闭宽限期。

“请假和打卡之间的关系怎么处理？”

答题思路：员工请假审批通过后，会在请假时间段内自动把对应的工作日考勤记录状态更新为“请假”。所以即使员工当天没有打卡，也不会出现“该上班却没打卡”的矛盾记录。

“系统的安全性怎么保障？”

答题思路：密码使用BCrypt加密存储，登录后的接口访问通过JWT Token鉴权，前后端分离架构天然避免了传统Session伪造问题。如果再加一层思考，可以提到管理端接口有角色校验，普通员工Token无法访问管理接口，这体现了基于角色的访问控制思路。

6.3 源码交付前的整理工作

毕业设计交付的源码、数据库文件、论文是一整套材料，最后提交前花一小时整理，能避免很多麻烦。源码里不要出现无意义的测试文件和调试代码，把application.yml里的数据库账号密码改成通用配置，旁边放一个说明文档注明“使用前请先导入数据库脚本并修改账号密码”。

代码注释要过一遍，重点方法补上块注释，说明方法的作用和参数含义。答辩时如果老师让你翻开代码看一段，有注释的代码和没有注释的代码体验差距很大。数据库脚本里加上DROP TABLE IF EXISTS的预处理语句，方便重新导入。

7. 部署运行与开发常见问题排查

7.1 本地环境搭建与项目启动流程

拿到完整的项目源码后，第一次把项目跑起来的流程是：先装JDK 1.8，确认环境变量生效，然后安装MySQL，创建数据库并导入SQL脚本，再用IDEA打开后端项目，等待Maven下载依赖并启动SpringBoot服务。前端用VSCode打开，在终端执行npm install安装依赖，然后npm run serve启动开发服务器，浏览器访问localhost:8080即可看到登录页。

这个过程中最常出问题的三个点：MySQL密码和application.yml里的不一致、后端端口8080被占用、前端依赖安装失败。给大家一个快速排查思路：前端npm install报错可以先清缓存再安装——npm cache clean --force然后重试；后端Maven依赖下载不下来就检查网络和阿里云镜像仓库配置。

7.2 SpringBoot版本过高引发的兼容性问题

SpringBoot版本太高的坑在开发过程中十分常见。比如选用SpringBoot 3.x后，MyBatis-Plus等第三方组件的配置方式发生了不少变化，很多网上找的教程还是老写法，照搬下来跑不通。还有JDK版本约束的问题，SpringBoot 3.x要求JDK 17，而学校实验室电脑或自己的电脑装的可能还是JDK 8。

在项目说明里我特意强调了推荐使用SpringBoot 2.7系列，这也是目前做毕设的稳妥保守方案。开发前先检查自己的环境，JDK版本不对就先装好，避免开发到一半因为环境问题被迫返工。

7.3 数据库连接与中文乱码问题

MySQL连接数据库时如果发现中文乱码，先检查建表时是否指定了utf8mb4字符集。连接串里也要显式加上characterEncoding=utf8。还有一个容易被忽略的点是MySQL 8.0及以上版本的驱动类名变了，从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver，旧驱动在MySQL 8上跑不起来。

7.4 前后端联调的常见问题

前后端分离开发时，联调阶段最容易出问题的就是跨域。开发环境下推荐用WebpackDevServer的proxy代理来解决，生产环境用Nginx反向代理，整体体验最顺滑。如果用后端直接加@CrossOrigin或全局CORS配置，注意处理预检请求，防止前端出现“Request failed with status code 401”的问题。

前端联调时先确认请求地址和请求参数无误，打开浏览器开发者工具看Network面板，把请求URL、状态码、响应内容看清楚再定位问题。很多“我以为后端出错了”的情况，最后发现是前端请求参数没传对或者后端接口路径写错了。

8. 从考勤系统毕设到真正的项目思维

做完这个考勤系统，我最大的感触是：毕业设计的意义不只是交付一个系统，更关键的是完整走一遍“需求分析——设计——开发——测试——文档”的软件工程流程。考勤系统麻雀虽小但五脏俱全，它涵盖了用户认证、权限控制、CRUD、审批流、数据统计、定时任务这些在企业级开发里的常见模块。

如果你在做的过程中卡在某个环节，换个思路试试。前后端联调通不过，就先把后端接口用Postman测一遍，确认接口没问题再排查前端；数据库表结构设计不确定，先画E-R图理清实体关系再动手建表；写论文没灵感，就先把系统的功能模块图、用例图、流程图画出来，图表有了文字自然就有了。

最后再分享一个小技巧：答辩时主动讲一两个开发中踩坑和解决的问题。比如“考勤统计的SQL最初在Java里做聚合，数据量大后再MySQL里用条件聚合解决了性能问题”，或者说“打卡的记录状态最初没有设计字段，后来根据请假和补卡场景增加了状态管理”。这种真实的问题解决经历，比背诵教材上的定义更能打动评审老师。

本文还有配套的精品资源，点击获取