SSM+Vue考勤管理系统:毕业设计完整设计与实现指南

发布时间:2026/10/22 14:43:02
SSM+Vue考勤管理系统:毕业设计完整设计与实现指南 做毕设这几年我被问得最多的一个选题就是考勤管理系统。尤其是标题里这种组合SSM框架加Vue前端配论文加整套程序几乎是计算机专业毕业设计的标配方向之一。这个题目的定位很清晰一套考勤管理系统前端用Vue做页面交互后端用SSMSpring SpringMVC MyBatis处理业务逻辑和数据持久化。说白了就是做一个能在线打卡、请假、审批、按月统计出勤情况的管理平台解决的痛点也很常见——手工纸制签到、Excel统计容易出错、请假流程靠口头传递这些老问题在中小型公司和部分高校场景里太典型了。这篇文章适合谁看两类人。一类是正在选毕设题目或者已经选了类似题目的同学你可以把它当成一份完整的设计参考另一类是工作上需要快速搭一个轻量考勤工具的前端或者后端开发者这套思路同样能落地。我会从技术选型、数据库设计、核心代码实现、论文写作、问题排查这几个维度拆开讲全程按真正做过的项目来复盘不是泛泛介绍功能。1. 项目整体的设计思路与技术选型1.1 技术选型为什么这套组合在毕设里这么稳先说架构。SSM作为经典的Java后端组合十几年下来沉淀了大量资料Spring管对象和依赖SpringMVC管接口路由MyBatis管SQL与对象映射。这个组合的稳定性和学习曲线都适合学生不会像微服务那样引入太多分布式概念也不会像纯Servlet那样代码量大到写不完。搭配Vue做前端是为了让页面交互更像现代Web应用而不是传统的模板套页面。我在带项目时经常被问到一个问题直接用JSPSSM代码量更小为什么还要专门引入Vue我的回答是如果你只求交差JSP确实更快但这几年评审老师对前后端分离这个点的关注度很高论文和答辩里能明确说清楚前端负责渲染、后端负责接口本身就是加分项。而且考勤系统有一个特点交互集中、数据刷新频繁比如打卡页面的时间显示、统计页面的动态图表、管理员对记录的实时操作这类场景用Vue的双向绑定和组件化确实比JSP手搓jQuery舒服得多。还有一个实际原因Vue生态里现成的UI组件库可以大量减少样式工作量。做毕设时间紧容易把时间耗在CSS上而考勤系统的后台管理页面本来就以表格和表单为主用现成库可以快速做出一个像样的界面。这也是很多同学选这个选题的原因之一——技术上不是最难但做出来看起来很完整。1.2 功能模块怎么划分才不显得凑数很多同学一上来就急着建表写代码结果做到一半发现模块之间互相纠缠不是缺功能就是重复造轮子。考勤系统建议按下面五个模块划分这也是我目前见过的同类项目中最合理的粒度用户模块包含用户注册、登录、角色区分学生/员工、管理员、审批人。这个模块是所有业务的基础一定要先做。考勤出勤模块用户每天签到、签退系统根据上下班时间自动判断状态正常、迟到、早退、缺勤。这个模块是系统的门面绝大部分交互都发生在这里。请假审批模块用户提交请假申请选择请假类型事假、病假、年假等和时间段审批人通过或者退回。这个模块能体现系统的业务完整度。统计报表模块按月或按周汇总每个用户的出勤数据支持按部门筛选用图表展示迟到率和缺勤率。这是论文里数据分析部分的最好素材。系统管理模块管理员维护用户信息、设置上下班时间、查看全站考勤记录、导出Excel报表。模块划分这块我吃过亏。早期我带的某位同学一开始把管理员和审批人拆成两个完全独立的用户表结果数据和权限对不上后来在论文里写得非常痛苦。实际上把角色设计成用户表里的一个字段然后再单独维护角色对应的功能权限比拆表要省事得多。模块的目的是理清业务不是把简单问题复杂化。2. 需求分析与数据库设计2.1 角色权限轻量设计比复杂设计更管用考勤系统涉及三类角色这是我在需求分析阶段就建议定的普通用户学生或员工打卡、查看自己的出勤记录、请假、查看自己的请假状态。审批人直属上级或辅导员查看下属的考勤和请假申请做审批操作。系统管理员管理用户账号、配置考勤规则、查看全部统计。这三类角色在操作边界上有明显区别但不需要引入Spring Security或者Shiro这种重量级权限框架。毕设阶段用简单的方式实现就够了后端写一个拦截器校验登录状态再根据用户角色字段放行特定接口。真正做权限控制的时候只需要在接口上标注管理员可访问或普通用户可访问的路径集合代码量不大效果却很清楚。论文里写基于角色的访问控制这个术语面试和答辩都能说得出口。2.2 核心数据表哪些字段不能缺数据库设计是这篇论文的骨架。我建议最少建四张表用户表id用户名密码MD5或BCrypt加密姓名角色部门状态创建时间。考勤记录表id用户id上班打卡时间下班打卡时间打卡日期状态正常/迟到/早退/缺勤备注。请假申请表id用户id请假类型开始时间结束时间请假事由审批状态待审批/通过/驳回审批意见申请时间。部门表可选id部门名称负责人id用于统计和筛选。这里有几个字段容易漏我专门说一下。首先是考勤记录表的唯一索引。同一用户同一天理论上只有一条考勤记录如果因为前端重复提交或者手滑点两次插入两条记录后面统计就会乱套。可以在用户id和打卡日期这两个字段上加联合唯一索引这是防重复最有效的办法。其次是时间字段的类型。我见过有同学用varchar存时间结果排序、计算迟到时长都非常别扭最后不得不改表。建议直接用datetime或timestamp类型Java后端统一用String返回前端格式化交给前端处理。第三是请假审批状态。用int类型存状态值0待审批、1通过、2驳回比直接存中文更规范代码里对状态做常量定义不然以后改需求的时候替换字符串会改到怀疑人生。2.3 ER图尽早画论文和程序才能同步推进这部分是我反复跟学生强调的数据库设计不是单独为写代码服务的更是为论文服务的。很多毕设论文的第二章就是需求分析和ER图如果你先画清楚ER图再写代码论文里直接复用即可如果代码写完了再补ER图往往会出现概念图和实际表结构对不上的尴尬。你只需要用任意绘图工具画出用户、考勤记录、请假申请的实体及关系用户和考勤记录是一对多用户和请假申请是一对多部门和用户是一对多。画完这张图数据库的表结构就已经在脑子里成型了代码实现只是时间问题。3. 开发前的环境准备与工程骨架搭设3.1 版本选型别盲目追新稳定才是硬道理我见过太多人卡在环境问题上并不是代码写不出来而是版本对不上。推荐这套经过验证的组合JDK 8兼容性最好的版本SSM框架对它的支持最完整。用JDK 17需要处理一堆模块化问题毕设没必要冒险。Maven 3.6用来管理依赖和构建后端工程。MySQL 5.7或8.0均可区别不大。注意MySQL 8需要改驱动包名和连接参数。Node.js 14以上 npm运行Vue项目和安装依赖。Vue CLI 4或5脚手架工具虽然Vite更快但Vue CLI在插件生态和文档数量上更适合新手。还有一个容易被忽略的点pom.xml里的依赖版本。Spring如果选4.x以上需要额外引入Jackson或Fastjson来处理JSON如果选Spring 3.x又会有Servlet版本不匹配的问题。我在下面给出一个经过实测的依赖组合思路spring-webmvc 5.x、mybatis 3.5.x、mybatis-spring 2.x、mysql-connector-java 8.0.x配合前端Vue 2 Element UI。Vue 3的问题在于Element UI不兼容要换成Element Plus公告和文章相对少一些所以毕设选Vue 2反而更稳。3.2 前后端分离的工程结构工程结构决定你后续写代码是否顺手。建议用两个独立目录backend放后端Spring工程frontend放前端Vue工程。后端按Maven标准结构建controller、service、mapper、entity、common五个包前端按Vue CLI默认结构建views放页面、router放路由、api放接口请求定义。有很多同学喜欢把前端文件硬塞到后端的webapp目录下想省一次部署。我的建议是别这么干原因有二第一前后端混在一起你改前端代码要重启后端服务开发效率极低第二论文里前后端分离这个亮点就没法写了。直接独立部署前端打包成静态文件放到Nginx后端打包成jar或war独立运行逻辑上清晰演示时也方便。3.3 初始化SQL脚本先造测试数据建表之后别急着写功能先把测试数据准备好。比如三到五个测试用户分别分配不同角色过去一个月的考勤记录造一些正常、迟到、早退、缺勤两三张请假申请单。有了这些数据每一轮开发都能立刻看到效果不用一行一行手敲。注意密码不要用明文可以先在SQL脚本里写一个固定加密串然后专心调逻辑。测试数据还有一个额外作用答辩演示老师通常会要求看看效果如果你当场现注册、现打卡时间很紧张提前造好数据可以直接进入统计页面展示月度报表和请假审批流程观感完全不一样。4. 后端核心功能实现4.1 登录与Token鉴权逻辑登录接口的逻辑不算复杂根据用户名查用户比对密码生成一个标识返回前端。常规做法是基于JWT生成token后续每次请求在请求头里带上这个token后端拦截器解析它得到当前用户信息。JWT生成的细节我多说几句。token里通常放userId和role两个自定义字段过期时间建议设置6到12小时别太短也别太长——太短用户频繁掉线太长安全性不好。密钥写死一个随机的长字符串放在配置文件里不要硬编码在代码中。解析失败的情况统一返回401状态码。这里面最容易踩坑的是密码校验。不要直接在代码里比对明文建议存储时用BCrypt或MD5加盐处理。数据库里不确定存了什么格式的话可以先用一个已知用户的加密串写死测试等逻辑通了再改注册接口的正常流程。4.2 打卡判断迟到、早退、缺勤的核心规则打卡是整个系统最有业务含量的部分。上班打卡时判断是否迟到下班打卡时判断是否早退。实现思路是配置一个上班时间比如09:00和一个下班时间比如18:00。用户打卡时把当前时间和配置时间比较当天第一次打卡记录为签到如果打卡时间晚于上班时间状态置为迟到当天第二次打卡记录为签退如果打卡时间早于下班时间状态置为早退如果一天只有签到没有签退或根本没有打卡状态置为缺勤。这个逻辑看似简单细节却不少。第一个坑是跨天加班用户到了晚上十一点半下班第二天凌晨一点打卡如果后端直接用当前日期判断会把它归到第二天。解决办法是打卡时间按小时计算比如当天18:00之后到次日06:00之前的打卡都算昨天的签退这样能覆盖大多数正常班次。第二个坑是时区问题服务器和数据库如果不加统一设置取出来的时间可能差8小时。建议MySQL连接串里加serverTimezoneAsia/ShanghaiJava后端统一使用系统默认时区。4.3 请假审批与状态流转请假模块的核心是状态流转。用户提交请假申请时记录申请时间、类型和时间段初始状态设为待审批。审批人看到的是所有待审批的申请可以选择通过或驳回驳回时要求填写审批意见。被驳回的申请普通用户能重新编辑提交也可以撤回待审批的申请。状态流转图在论文里特别好画一个流程图就把整个业务串起来了。实现上只需要在更新语句里加一个判断只有当前状态等于待审批才能更新为通过或驳回。这个条件在SQL里写清楚能防止用户通过改请求参数非法篡改状态。4.4 考勤统计报表的SQL实践统计报表是对外展示的重要环节。按月统计每个用户出勤情况时需要按user_id和月份分组用条件聚合统计正常天数、迟到次数、早退次数、缺勤天数。SQL大致是SELECT user_id, DATE_FORMAT(work_date, %Y-%m) AS month, SUM(status 1) AS normal_days, SUM(status 2) AS late_days, SUM(status 3) AS leave_early_days, SUM(status 4) AS absent_days FROM attendance_record WHERE work_date BETWEEN #{startTime} AND #{endTime} GROUP BY user_id, month这个SQL在MyBatis里写时要注意参数如果是DateTime类型MyBatis需要设置jdbcType否则可能报参数类型不匹配。另外如果统计数据不需要实时强烈建议每天凌晨用定时任务把前一天的数据汇总到一张统计表查询速度会快很多答辩的时候加载数据也会显得流畅。5. 前端页面与交互实现5.1 页面骨架Vue Element UI的组合前端页面我建议按这个清单来建登录页用户名、密码输入框POST调后端登录接口存储token和用户信息。首页/仪表盘显示当前登录用户的基本信息、今日状态是否已打卡、是否迟到、近期考勤记录。考勤打卡页显示当前时间、签到和签退两个按钮以及今日打卡状态。个人考勤记录页展示自己的历史记录列表支持按月份筛选。请假申请页表单填写请假类型、起止时间、事由提交后可查看审批状态。审批管理页审批人可见待审批列表通过或驳回操作。用户管理页管理员可查看、新增、禁用用户修改角色。考勤统计页管理员按部门、月份查看汇总数据列表加图表展示。页面数量不用多8个左右已经足够撑起一个完整的前端工程。如果你不熟悉Element UI可以先用它的表格组件写一个列表页跑通数据展示链路再逐步加复杂表单。5.2 Axios请求封装与路由守卫前端和后端交互靠Axios。统一封装一个request工具类设置baseURL为后端的接口地址然后在请求拦截器中从localStorage取token放在Authorization请求头里。响应拦截器统一处理HTTP状态码401跳回登录页其他错误提示后端返回的message。路由守卫是另一个必须做的点。Vue Router的beforeEach里判断访问目标是否在白名单内如登录页不在白名单且没有token直接重定向到登录页。另外根据用户角色做菜单级别的显隐控制普通用户不显示审批管理入口管理员不显示个人请假入口这种前端控制体验、后端控制安全的分工是最合理的。5.3 打卡页面的交互细节打卡页面最核心的就是时间展示和按钮状态。时间展示用setInterval每秒钟更新一次当前时间让用户直观看到打卡时间。按钮状态要根据后端返回的今日记录判断已经打过上班卡但没有下班卡时签到按钮置灰、签退按钮可用两个都打过了两个按钮都置灰。这个判断逻辑前端做就行后端仍然会校验重复打卡双保险。如果要加一点高可用效果可以在打卡页展示打卡地点距离用浏览器定位计算经纬度和公司坐标的距离。但这一步可做可不做会增加不少代码量和错误处理。如果时间和精力允许可以作为论文的扩展功能提一下不用深入实现。6. 论文怎么写才能不踩坑6.1 目录结构从摘要到结束一个都不能少论文结构通常分七章第一章 绪论研究背景、意义、国内外现状、本文主要工作。第二章 相关技术介绍SSM框架、Vue、Element UI、MySQL。第三章 需求分析功能需求、非功能需求安全性、易用性、用例图。第四章 系统设计总体设计架构图、数据库设计ER图、模块详细设计。第五章 系统实现分模块贴核心代码和界面截图配关键实现说明。第六章 系统测试功能测试用例表、测试结果、性能测试或兼容性测试。第七章 总结与展望总结系统成果说明不足和后续改进方向。这个目录是同类系统论文最常见的结构也基本是高校评审老师默认接受的框架。第二章不用写太深一两页介绍技术是什么、优缺点就行重心一定要放在第四章和第五章这两章最体现工作量。6.2 把技术点讲出亮点论文的深度主要体现在对关键技术的表述上。比如登录鉴权不要只写使用JWT技术实现登录而是拆成签发流程、校验流程、过期处理三个点再画一个时序图说明前后端交互过程。再比如考勤状态判断可以画一个简单流程图把上班打卡时间和下班打卡时间作为判断分支然后在文字里把边界情况跨天、重复打卡、请假当天都写清楚。这样论文的篇幅和含金量同时上来了答辩时被问到细节也不会心虚。6.3 查重与答辩的经验查重最有效的办法不是改句子而是五章里的系统实现放自己真实写的代码和真实截图。代码块本身不会被查重匹配太多而且是自己写的怎么问都答得上来。数据库设计的表结构说明、状态字段含义这些内容尽量用自己的语言重述因为教科书和别人的论文里多半已经写过一遍。答辩前准备三个问题的答案基本就稳了为什么选这个技术栈、数据库为什么这样设计、最难解决的bug是什么。第三个问题尤其重要按照第七章常见问题部分的实际经历来讲评审老师最喜欢听到真实的排查过程。7. 常见问题与排查清单实录7.1 跨域问题导致接口调不通前后端分离开发时最常遇到的就是跨域。浏览器控制台报Access-Control-Allow-Origin相关错误就是后端没有设置跨域头。处理办法在后端加一个配置类注册CorsFilter允许所有来源、所有方法、所有请求头重点是允许Authorization这个请求头否则前端带了token也会被拦。另一个办法是在Vue的devServer里配置代理把/api前缀转发到后端地址开发时推荐这种方式。7.2 打卡时间差了8小时或直接报错这个问题几乎每一个做考勤系统的都会遇到一次。根源在数据库时区。连接串里务必加serverTimezoneAsia/Shanghai和useSSLfalse两个参数前者修正时区后者避免连接警告。另外MySQL 8的驱动已经是com.mysql.cj.jdbc.Driver不要再写旧的com.mysql.jdbc.Driver否则启动直接失败。7.3 MyBatis映射文件里字段名对不上数据库字段user_id在Java实体类里如果写成userIdMyBatis默认自动映射是可以转的但前提是数据库配置了mapUnderscoreToCamelCasetrue。如果不设置SQL查询出来的user_id赋不到userId属性上结果全是null。建议直接给MyBatis加这个全局配置省去写一堆resultMap的麻烦。7.4 前端打包后刷新页面404这是因为前端路由是前端管理的历史模式页面刷新时请求了后端不存在的路径。解决办法如果是部署在Nginx配置一个try_files把所有路径都指向index.html如果是部署在Tomcat尽量用hash模式的路由。毕设演示期间我建议直接用hash模式文件名带#号看起来虽然不够现代但绝对稳定。7.5 部署上线怎么把程序和论文沉淀成完整交付物做完开发最后一步是打包部署。后端用Maven的package打成war包或jar包前端用npm run build生成dist目录然后把dist放到Nginx的html目录反向代理到后端接口地址。如果你的答辩环境只有一台电脑可以直接在本地同时启动后端服务和Nginx演示效果和线上没有区别。交付的时候把完整工程、SQL脚本、部署说明、论文Word文档放在一个文件夹里压缩这就是一套让谁都挑不出毛病的完整毕设。我个人带项目时最深的体会有两点。第一考勤系统不像社交或电商项目有那么大的想象空间但正因为业务边界清楚、技术覆盖面广它反而非常适合作为毕设选题——你能在有限的时间里把登录、权限、CRUD、统计、状态流转和前端交互全部过一遍这对第一次完整做项目的人来说价值非常大。第二做这个系统别急着写代码先花三到五天把数据库设计和接口清单定下来后面至少能少熬一个星期的夜。如果你现在正在为这个题目发愁按这篇文章的顺序走一遍程序加论文基本上就稳了。

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询