企业官网建设流程全解析

做高校类的信息管理系统，这几年确实是一个热门方向。不管是实验室的课题、毕业设计，还是课程综合实践，最常见的组合就是SpringBoot + Vue + MySQL这一套。我手上正好有一个"高校健康信息管理Web系统"的完整项目，前后端分离，基于SpringBoot + Vue + MyBatis + MySQL实现，功能覆盖了信息采集、健康打卡、异常上报、数据统计、角色权限管理等模块。这篇文章我就围绕这套系统的源码结构、核心设计思路、数据库建模、关键接口实现和踩坑记录做一个完整拆解，希望能给正在做同类系统的同学一些参考，也适合想把前后端分离项目吃透的开发者对照练习。

1. 项目整体规划与技术选型

1.1 需求从哪来、要解决什么问题

先说清楚这个系统到底是干什么的。高校场景下，人员流动性大，学生、教师、后勤保障人员、临时访客，每天都要进出校园、出入宿舍和教学楼。传统的体温纸质登记、人工汇总方式效率太低，数据散落、难追溯、难统计，一旦出现问题根本查不到完整轨迹。所以这个系统的核心目标就是一件事：把校园内各类人员的健康状态和位置流动信息，用数字化方式统一管起来。

具体拆下来，业务上需要解决这几个问题：

• 全校师生每天的健康信息采集，比如体温、健康状况、所在地、行程轨迹；
• 异常情况的快速上报和跟进处理；
• 不同角色（学生、辅导员、学院管理员、校级管理员）对数据有不同的查看和操作范围；
• 各类统计报表的自动生成，避免手动整理Excel的重复劳动。

我当初做这套系统的时候，并没有把它简单当成一个CRUD项目来做。因为这类系统的难点不在于单表增删改查，而在于角色权限的粒度控制、个人健康数据的时效性跟踪、以及批量导入导出和统计报表这些真实业务场景。如果你只是照着网上的模板抄一遍，写完发现只能登录、看个列表，那离"能用"差得还远。

1.2 为什么是这套技术栈

这套系统用的是SpringBoot + Vue + MyBatis + MySQL的组合，属于当前Java后端开发里非常主流、也非常适合教学和项目落地的架构。

选择它的理由，我实际做下来有几点体会：

• SpringBoot负责快速搭建后端服务。它内嵌了Tomcat，不需要额外部署容器，一个可执行Jar就跑了。对于这个体量的管理系统来说，开发效率和部署成本都非常友好。
• Vue负责前端页面和交互。配合Element UI组件库，表格、表单、弹窗、分页这些后台管理页面最常用的组件开箱即用，能在很短的时间做出专业感很强的界面。
• MyBatis负责数据库访问层。相比JPA，MyBatis的SQL语句完全可控，尤其在多表关联查询和复杂统计场景下，写SQL比自动生成要更直观、更容易优化。项目里大量自定义SQL都用在了报表统计上，用MyBatis非常适合。
• MySQL负责数据持久化。轻量、稳定、社区资料多，作为这个量级的系统数据库绰绰有余。

这套组合还有一个好处：前后端完全分离，前端通过RESTful接口访问后端，以后想扩展移动端、小程序端，接口层是可以直接复用的，不用另起炉灶。

2. 系统功能模块拆解

2.1 用户角色与权限体系

权限设计是这个系统里我认为最值得讲的部分。整个系统划分了四种角色，每一种角色看到的东西、能做的操作都不一样。

这个设计背后对应的是一个很典型的RBAC（基于角色的访问控制）模型。实现上我用了两套方案配合：

• 前端根据登录用户的角色动态生成菜单。路由配置里通过meta字段标记当前路由允许访问的角色数组，登录后根据角色的permissions字段过滤出可见菜单，没有权限的路由直接不注册。
• 后端接口通过拦截器校验JWT Token，Token里存用户ID和角色标识。在需要限制数据范围的地方，例如辅导员查询学生记录，后端会根据当前登录用户绑定班级的条件自动拼接查询SQL的where条件。

这里有一个很多人会忽略的细节：前端菜单隐藏不等于后端安全。接口一定要做二次校验，否则别人知道接口地址就能直接调。这个系统里的所有查询接口都强制从Token解析当前用户身份，再根据身份决定查询范围，绝不相信前端传过来的"我是谁"。

2.2 核心业务模块划分

从功能模块上看，系统主要包含以下六块：

1. 用户认证模块：登录、注销、密码修改、密码加密存储。
2. 健康打卡模块：每日一次填报体温、健康状况、当前所在地、是否接触异常人员，提交后当天不可重复提交。
3. 异常上报与处理模块：学生上报异常后，系统自动通知辅导员，辅导员填写处理意见并标记状态（待处理、已处理、已隔离等）。
4. 消息通知模块：系统发布通知公告，按角色推送，学生端和教师端都能看到。
5. 统计报表模块：按院系、班级、日期维度统计打卡率、异常人数，支持导出Excel。
6. 系统管理模块：用户管理、班级管理、院系管理、系统参数配置。

每个模块之间是有业务关联的，不是孤立的一堆表格。比如打卡模块产生的数据会实时刷新统计报表，异常上报会联动通知模块。这要求你在做表设计的时候就要把关联关系理清楚，否则后面业务一复杂，代码会越写越乱。

3. 数据库设计与建模要点

3.1 表结构设计思路

这套系统的数据库我一共设计了10张核心表，这里挑几个关键的表来说。

用户表（sys_user）

CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `username` varchar(50) NOT NULL COMMENT '登录账号', `password` varchar(100) NOT NULL COMMENT '密码（BCrypt加密）', `real_name` varchar(50) NOT NULL COMMENT '真实姓名', `role` tinyint(4) NOT NULL COMMENT '角色：1-学生 2-辅导员 3-学院管理员 4-校级管理员', `class_id` bigint(20) DEFAULT NULL COMMENT '所属班级ID（学生和辅导员）', `college_id` bigint(20) DEFAULT NULL COMMENT '所属学院ID', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `status` tinyint(4) DEFAULT '1' COMMENT '状态：1-正常 0-禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表';

有几个设计上的考虑我想特别说明一下：

• 密码用BCrypt加密存储，不存明文。网上很多demo项目把密码直接放数据库里，这个是绝对要避免的，一旦数据库泄露，所有账号全部暴露。
• 用tinyint存角色，比直接存字符串更省空间，也方便扩展。但要注意规范好各数值对应的角色，我建议在Java代码里用枚举类定义好，不要散落在业务代码里写魔法数字。
• class_id、college_id用逻辑关联，没有物理外键。生产环境我基本不建物理外键，因为后续做数据迁移、分库分表的时候物理外键是很大的负担，外键约束放在应用层控制就够了。

健康打卡记录表（health_report）

CREATE TABLE `health_report` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '用户ID', `report_date` date NOT NULL COMMENT '填报日期', `temperature` decimal(4,2) NOT NULL COMMENT '体温读数', `health_status` tinyint(4) NOT NULL COMMENT '健康状况：1-正常 2-异常', `location` varchar(200) DEFAULT NULL COMMENT '当前所在地', `is_contact_risk` tinyint(4) DEFAULT '0' COMMENT '是否接触风险人员：0-否 1-是', `remark` varchar(500) DEFAULT NULL COMMENT '备注说明', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_date` (`user_id`, `report_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='健康打卡记录表';

这里最关键的是一个联合唯一索引：uk_user_date(user_id, report_date)。它的作用是保证同一个用户同一天只能提交一条打卡记录。这个约束如果不放在数据库层，而只靠代码判断，并发情况下就会出现同一用户同一天提交两条数据的情况。很多初学者想不到这一层，等到出问题了才回来补索引。

3.2 MyBatis操作中的两个实用经验

用MyBatis操作这批表，我有两个比较实用的经验可以分享。

第一个：批量插入要用动态SQL的foreach标签。比如管理员批量导入学生的每日健康数据，一条条插入显然太慢。用MyBatis的foreach拼成一条批量insert语句，几千条数据从秒级降到毫秒级，效果立竿见影。

<insert id="batchInsert"> INSERT INTO health_report (user_id, report_date, temperature, health_status, location) VALUES <foreach collection="list" item="item" separator=","> (#{item.userId}, #{item.reportDate}, #{item.temperature}, #{item.healthStatus}, #{item.location}) </foreach> </insert>

第二个：复杂统计查询用resultMap映射到自定义DTO。学生健康信息管理系统最核心的报表就是"XX学院XX班级某天的打卡率"。这个统计要关联三张表：用户表拿班级和学院信息，打卡记录表拿实际打卡状态，班级表拿应到人数。这种查询用MyBatis的resultMap把结果映射到DailyReportVO这种自定义对象上，比返回Map<String, Object>要清晰得多，后续前端拿数据也更方便，接口层不用再做一次类型转换。

4. 后端核心接口实现细节

4.1 SpringBoot整体分层结构

项目的后端包结构是非常清晰的分层模式，我建议你也保持这个习惯：

com.example.campushealth ├── common // 通用常量、工具类、通用返回结果类 ├── config // 配置类：CORS跨域、拦截器、验证码等 ├── controller // 接口层：接收请求、参数校验、返回结果 ├── service // 业务层：核心业务逻辑、事务控制 │ └── impl // 业务实现类 ├── mapper // MyBatis接口层：数据库访问 ├── entity // 数据库表对应的实体类 ├── dto // 数据传输对象：接收前端参数 ├── vo // 视图对象：返回给前端的数据封装 └── utils // 工具类：日期处理、Excel导入导出等

这种分层的好处是一目了然，每一层的职责单一。Controller不做业务、只做参数接收和结果返回；Service层只做业务逻辑，不碰SQL；Mapper只做数据访问。我见过很多项目把业务逻辑写在Controller里，或者把SQL拼写在Service里，短期看是省事了，后期维护绝对让人头大。

一个比较值得提的点是通用返回结果类的设计。我封装了一个Result<T>，包含code、message、data三个字段，所有接口统一返回这个结构。

@Data 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(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }

统一返回结构之后，前端封装的请求工具就只需要处理这一个结构，拦截器里判断code === 200就正常返回数据，否则弹错误提示。省掉了大量重复的异常处理代码。

4.2 关键业务接口实现示例

这里选两个有代表性的接口说一下具体实现思路。

第一个是健康打卡接口。前端提交内容包括体温、健康状况、所在地等。后端要做三层检查：

• 当前用户是否登录（拦截器已处理）；
• 该用户今天是否已经打过卡（查health_report表的联合唯一索引）；
• 提交的参数是否合法（体温范围35.0到42.0，健康状态是否是枚举值）。

如果已经打过卡了，直接返回给前端"今日已填报，请勿重复提交"的提示。这里我用了一个比较优雅的处理方式：直接用数据库的INSERT语句，捕获唯一索引冲突异常，冲突了就返回重复打卡，避免先查再插的竞态条件。

@Override @Transactional(rollbackFor = Exception.class) public Result<String> submitReport(ReportSubmitDTO dto) { Long userId = SecurityUtils.getCurrentUserId(); HealthReport report = new HealthReport(); report.setUserId(userId); report.setReportDate(LocalDate.now()); report.setTemperature(dto.getTemperature()); report.setHealthStatus(dto.getHealthStatus()); report.setLocation(dto.getLocation()); try { healthReportMapper.insert(report); } catch (DuplicateKeyException e) { return Result.error(400, "今日已填报，请勿重复提交"); } // 如果健康状态异常，同步生成一条待处理记录给辅导员 if (dto.getHealthStatus() == 2) { abnormalRecordService.createAbnormalRecord(userId, "健康打卡状态异常"); } return Result.success("填报成功"); }

第二个是分页查询打卡记录接口。这个接口需要支持按日期范围、按健康状态、按用户姓名等多条件组合查询，同时返回分页信息。我用的是PageHelper分页插件，一行代码搞定分页。

@Override public PageResult<ReportVO> queryReportPage(ReportQueryDTO query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); List<ReportVO> list = reportMapper.selectReportPage(query); PageInfo<ReportVO> pageInfo = new PageInfo<>(list); return PageResult.of(pageInfo.getList(), pageInfo.getTotal()); }

这里要提醒一句：PageHelper分页必须要紧跟在要分页的查询语句之前，中间不能穿插其他数据库操作，否则分页会作用到错误的SQL上。这是PageHelper最常见的坑，我踩过不只一次。

4.3 文件导入导出功能的落地

统计报表导出Excel，是这个项目的一个亮点功能。我用的方案是EasyExcel，相较于传统的POI，它封装更简单、内存占用更低，尤其适合大数据量导出场景。

导出的实现思路是：先把查询到的统计数据构造成List对象，然后一行注解标注字段与Excel表头的对应关系，调用EasyExcel的write方法直接输出到HttpServletResponse的输出流。前端下载时只要发一个GET请求，后端通过响应头的Content-Disposition告诉浏览器这是一个需要下载的文件即可。

导入也是同样的思路，管理员上传一个Excel文件，后端用EasyExcel读取每一行，校验数据合法性后再批量写入数据库。导入最容易出问题的就是数据格式校验，比如日期格式不对、体温超过正常范围、学号不存在。我用了EasyExcel的监听器在读取时逐行校验，遇到错误行就记录错误原因，收集完成后一次性返回给前端，明确告诉用户是第几行、哪个字段有问题。这样用户不用猜，直接改文件重传就行。

5. 前端Vue页面与交互实现

5.1 前端工程结构与路由设计

前端这一块我用的是Vue 2 + Element UI + Axios + Vue Router + Vuex这套比较成熟的技术组合。虽然现在Vue 3已经是主流，但Vue 2的资料多、坑少，对于管理系统类的项目依然是非常稳妥的选择。如果你现在自己学习，我更推荐直接用Vue 3 + Vite + Element Plus，安装依赖和启动速度都会明显改善。

页面结构上，整体采用经典的左侧菜单+右侧内容区的后台管理布局。路由配置按照模块拆分成独立的子路由，例如：

/src ├── router │ └── index.js // 路由表 ├── api // 接口请求封装 │ ├── report.js │ ├── user.js │ ├── statistics.js │ └── sysManage.js ├── views // 页面组件 │ ├── login.vue // 登录页 │ ├── dashboard.vue // 工作台（健康概览） │ ├── report │ │ ├── dailyReport.vue // 每日打卡 │ │ ├── reportHistory.vue // 打卡记录 │ │ └── abnormalHandle.vue // 异常处理 │ ├── statistics │ │ └── collegeStats.vue // 统计数据 │ └── system │ ├── userManage.vue // 用户管理 │ └── classManage.vue // 班级管理 └── utils

路由守卫的处理是权限控制的关键一环。我在路由的meta字段里加了一个roles数组，每次跳转前检查当前用户角色是否在允许列表里。如果没有权限，直接重定向到工作台并提示"无权访问该页面"。

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (!token && to.path !== '/login') { next('/login'); return; } const userRole = store.state.user.role; if (to.meta.roles && to.meta.roles.indexOf(userRole) === -1) { next('/dashboard'); return; } next(); });

5.2 Axios请求封装与前后端联调

前后端分离项目里，Axios请求封装的好坏直接影响开发效率和维护成本。我在utils/request.js里统一创建了一个Axios实例，配置了baseURL，然后再通过请求拦截器和响应拦截器做两件事：

• 请求拦截器：每次请求自动携带JWT Token到请求头的Authorization字段，无需每个接口手动传；
• 响应拦截器：统一判断后端返回的code字段，如果等于200则直接返回data给业务代码，否则弹出错误提示并reject。

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = 'Bearer ' + token; } return config; }); 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.data; }, error => { // 处理401未授权、403无权限等状态码 if (error.response && error.response.status === 401) { localStorage.clear(); router.push('/login'); } Message.error(error.message || '请求失败'); return Promise.reject(error); } );

这样做的好处非常明显，业务代码里几乎看不到if-else处理错误分支的逻辑，每个接口调用都是干干净净的：

// 提交健康打卡 async submitReport() { const res = await submitDailyReport(this.form); this.$message.success(res); this.loadHistory(); }

实际联调阶段，我建议后端开发时把Swagger或者接口文档工具用起来，把每个接口的请求参数和返回结构定义清楚。这个项目里我配了Swagger UI，页面路径直接访问就能看到所有接口的在线文档，前端照着文档就能对接，不用反复找后端问字段含义。这能省掉相当多的沟通成本。

6. 常见问题与排查技巧实录

6.1 问题速查表

实际开发过程中，我遇到了不少问题，这里整理一个速查表，如果你做同类项目时碰到相似的情况可以直接对照排查。

6.2 几个印象比较深的坑

第一个坑是关于时间区的。本地开发时打卡记录一切正常，部署到服务器后，用户晚上23:50打的卡被记录成了第二天的数据。排查后发现是服务器系统时区与数据库时区不一致，JVM连接MySQL时用了默认的时区。解决方案是在数据库连接URL里显式指定时区参数：serverTimezone=Asia/Shanghai，同时在Java代码里统一用LocalDate和LocalDateTime而不使用java.util.Date，避免隐性的时区转换。

第二个坑是文件上传大小限制。项目中有一个批量导入学生信息的接口，上传的Excel稍大一点就提示"请求资源不可用"或者直接报404。追查后发现问题在SpringBoot默认的max-file-size是1MB，超过就被拦截了。在配置文件中调整：

spring: servlet: multipart: max-file-size: 20MB max-request-size: 20MB

很小的一行配置，但不踩一次根本想不到是这个原因。

第三个坑是关于数据库连接池的配置。开发的时候并发量低，没感觉到什么，部署后做了一个小小的并发压测，结果数据库连接直接被打满，报错HikariPool-1 - Connection is not available, request timed out after 30000ms.。原因是HikariCP默认最大连接数是10，在并发查询场景下不够用。后来调整为：

spring: datasource: hikari: maximum-pool-size: 30 minimum-idle: 10 connection-timeout: 30000

这里想提一句我个人的运维经验：连接池的数量不要盲目调大，它要结合数据库本身的max_connections来配置，否则应用层的池子再大，数据库层扛不住一样是白忙活。一般建议应用连接池上限，保持在数据库最大连接数的50%到60%左右，留出余量给管理操作和其他应用。

6.3 从"能跑"到"能上线"需要做哪些事

很多学生做的项目停留在"本地能跑"的阶段，但真正要交付部署，还有几件事是必须做的。这也是我给做过这个项目之后复盘出来的经验清单：

第一，密码和敏感信息必须加密处理。数据库里用户的密码一律用BCrypt加密存储，绝对不允许明文。项目配置文件里的数据库密码，部署时通过环境变量注入，不要写死在代码仓库里。

第二，数据备份策略要提前定。高校场景下，健康数据是需要追溯的历史数据，不能丢。我建议至少每天做一次MySQL全量备份，备份文件保留30天。一个简单的crontab脚本就能完成，不要等数据丢了再后悔。

第三，日志策略要规范。至少要有操作日志和错误日志的区分。我建议你在系统里加一个简单的操作日志表，记录登录、打卡、异常处理、数据导出等关键操作。出了问题的时候，这个表能帮你快速定位是谁、在什么时间、做了什么操作。

第四，部署前做一遍安全自查。对外暴露的管理系统，至少这几项要检查：登录接口是否有验证码或频率限制措施、跨域配置是否限制为可信来源、默认的管理员账号密码是否已经修改、接口是否做了传参校验。

我个人在实际使用中最大的体会是：这类信息管理系统的代码难度其实没有多高，真正拉开差距的是对业务的理解和边界情况的处理。把重复打卡的并发问题想清楚、把不同角色的数据隔离想清楚、把导出大数据量时的内存和速度问题想清楚，这套系统的价值就体现出来了。希望这篇拆解对正在做类似项目的你有所启发，照着这个思路去完善你的系统，能少走不少弯路。