企业官网建设流程全解析

做毕设这几年，我被问得最多的一个选题就是"考勤管理系统"。尤其是标题里这种组合：SSM框架加Vue前端，配论文加整套程序，几乎是计算机专业毕业设计的标配方向之一。

这个题目的定位很清晰：一套考勤管理系统，前端用Vue做页面交互，后端用SSM（Spring + SpringMVC + MyBatis）处理业务逻辑和数据持久化。说白了就是做一个能在线打卡、请假、审批、按月统计出勤情况的管理平台，解决的痛点也很常见——手工纸制签到、Excel统计容易出错、请假流程靠口头传递，这些老问题在中小型公司和部分高校场景里太典型了。

这篇文章适合谁看？两类人。一类是正在选毕设题目或者已经选了类似题目的同学，你可以把它当成一份完整的设计参考；另一类是工作上需要快速搭一个轻量考勤工具的前端或者后端开发者，这套思路同样能落地。我会从技术选型、数据库设计、核心代码实现、论文写作、问题排查这几个维度拆开讲，全程按真正做过的项目来复盘，不是泛泛介绍功能。

1. 项目整体的设计思路与技术选型

1.1 技术选型：为什么这套组合在毕设里这么稳

先说架构。SSM作为经典的Java后端组合，十几年下来沉淀了大量资料，Spring管对象和依赖，SpringMVC管接口路由，MyBatis管SQL与对象映射。这个组合的稳定性和学习曲线都适合学生：不会像微服务那样引入太多分布式概念，也不会像纯Servlet那样代码量大到写不完。搭配Vue做前端，是为了让页面交互更像现代Web应用，而不是传统的模板套页面。

我在带项目时经常被问到一个问题：直接用JSP+SSM，代码量更小，为什么还要专门引入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连接串里加serverTimezone=Asia/Shanghai，Java后端统一使用系统默认时区。

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小时或直接报错

这个问题几乎每一个做考勤系统的都会遇到一次。根源在数据库时区。连接串里务必加serverTimezone=Asia/Shanghai和useSSL=false两个参数，前者修正时区，后者避免连接警告。另外MySQL 8的驱动已经是com.mysql.cj.jdbc.Driver，不要再写旧的com.mysql.jdbc.Driver，否则启动直接失败。

7.3 MyBatis映射文件里字段名对不上

数据库字段user_id在Java实体类里如果写成userId，MyBatis默认自动映射是可以转的，但前提是数据库配置了mapUnderscoreToCamelCase=true。如果不设置，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、统计、状态流转和前端交互全部过一遍，这对第一次完整做项目的人来说价值非常大。第二，做这个系统别急着写代码，先花三到五天把数据库设计和接口清单定下来，后面至少能少熬一个星期的夜。如果你现在正在为这个题目发愁，按这篇文章的顺序走一遍，程序加论文基本上就稳了。