SeigRobotics1. 项目背景与需求分析
2020年以来的全球公共卫生事件让高校管理面临前所未有的挑战。作为一名长期从事校园信息化建设的开发者，我深刻理解传统人工登记、纸质审批的防疫管理方式已无法满足现代高校需求。这正是我们团队决定开发这套"基于Java的大学生疫情在校封闭管理系统"的初衷。
系统核心要解决三个痛点：
- 学生健康信息采集效率低下 - 传统晨午检需要班干部手动统计，误差率高且耗时
- 请假审批流程冗长 - 从申请到辅导员审批往往需要1-2天
- 数据统计分析困难 - 校领导难以及时掌握全校疫情动态
我们对比了三种技术路线：
- 原生App（Android/iOS）：开发成本高，需要维护两套代码
- 微信小程序：功能受限，数据安全性存疑
- B/S架构Web系统：跨平台、易维护、扩展性强
最终选择Java+SSM的技术栈，主要基于：
- Java的跨平台特性：一套代码适应Windows、Mac、Linux等不同管理员终端
- SSM框架的成熟度：Spring MVC+Spring+MyBatis组合经过大量企业级项目验证
- MySQL的高性价比：相比Oracle等商业数据库，更适合高校预算
提示：系统设计时要特别注意《个人信息保护法》要求，学生敏感信息如家庭住址需加密存储
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统架构设计
2.1 技术选型解析
系统采用经典的三层架构，各层技术选型如下：
| 层级 | 技术组件 | 选型理由 | 典型应用场景 |
|---|---|---|---|
| 表现层 | JSP+AJAX | 页面动态渲染能力强 | 请假申请表单提交 |
| 业务层 | Spring | IOC容器管理Bean | 打卡业务逻辑处理 |
| 持久层 | MyBatis | SQL灵活可控 | 复杂查询如历史打卡记录 |
数据库选用MySQL 8.0，主要考虑：
- 高校场景下预计最大并发量<500，MySQL完全胜任
- JSON字段支持：便于存储动态扩展的健康问卷
- 窗口函数：简化"连续打卡天数"等统计计算
2.2 功能模块设计
系统功能架构如图所示：
plaintext复制大学生疫情在校封闭管理系统
├── 学生端
│ ├── 每日健康打卡
│ ├── 请假申请
│ └── 行程上报
├── 教师端
│ ├── 学生健康监控
│ └── 请假审批
└── 管理员端
├── 数据统计分析
└── 系统配置管理
核心模块实现要点：
- 打卡模块：采用GeoLite2进行定位校验，防止代打卡
- 审批流引擎：基于Activiti实现多级审批（辅导员→院领导）
- 数据看板：使用ECharts可视化展示各院系打卡率
3. 核心功能实现
3.1 健康打卡功能实现
前端采用响应式设计，关键代码片段：
html复制<form id="healthForm">
<div class="form-group">
<label>今日体温</label>
<input type="number" class="form-control" name="temperature"
min="35" max="42" step="0.1" required>
</div>
<!-- 其他健康指标字段 -->
<button type="submit" class="btn btn-primary">提交</button>
</form>
后端处理逻辑：
java复制@PostMapping("/submitHealthCheck")
public Result submitHealthCheck(@Valid HealthRecord record,
HttpServletRequest request) {
// 获取学生ID从Session
String studentId = (String) request.getSession().getAttribute("userId");
// 校验当日是否已打卡
if(healthService.checkSubmittedToday(studentId)){
return Result.error("今日已提交，请勿重复操作");
}
// 保存记录
record.setStudentId(studentId);
healthService.saveRecord(record);
return Result.ok("打卡成功");
}
注意事项：体温字段需客户端和服务端双重校验，防止恶意提交异常值
3.2 请假审批流程设计
请假状态机设计：
mermaid复制stateDiagram
[*] --> 待审批
待审批 --> 已批准: 辅导员通过
待审批 --> 已驳回: 辅导员拒绝
已批准 --> 已销假: 学生返校确认
关键数据库表结构：
sql复制CREATE TABLE `leave_application` (
`id` bigint NOT NULL AUTO_INCREMENT,
`student_id` varchar(20) NOT NULL COMMENT '学号',
`start_time` datetime NOT NULL COMMENT '开始时间',
`end_time` datetime NOT NULL COMMENT '结束时间',
`reason` text COMMENT '请假原因',
`status` enum('pending','approved','rejected') DEFAULT 'pending',
`approver_id` varchar(20) DEFAULT NULL COMMENT '审批人ID',
PRIMARY KEY (`id`),
KEY `idx_student` (`student_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
4. 系统安全与性能优化
4.1 安全防护措施
-
认证授权：
- 采用Shiro框架实现RBAC
- 密码存储使用BCrypt加密
- 关键操作（如审批）需二次认证
-
数据安全：
- 敏感字段如手机号进行AES加密
- 数据库定时备份到校内NAS
- 操作日志保留180天
4.2 性能调优实践
通过JMeter压力测试发现：
- 并发100用户时，打卡接口响应时间>3s
- 原因分析：频繁查询redis造成网络IO瓶颈
优化方案：
- 引入本地缓存Caffeine
- 批量提交健康数据
- 数据库连接池调整为HikariCP
优化后性能对比：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 平均响应时间 | 3200ms | 450ms |
| 最大并发数 | 150 | 500+ |
| CPU使用率 | 85% | 45% |
5. 部署与运维方案
5.1 服务器环境配置
推荐部署方案：
- 应用服务器：Tomcat 9.x + JDK11
- 数据库服务器：MySQL 8.0（8核16G内存）
- 操作系统：CentOS 7.6
启动参数配置示例：
bash复制# Tomcat配置
export JAVA_OPTS="-Xms2048m -Xmx2048m -XX:+UseG1GC"
5.2 日常运维要点
-
监控指标：
- 应用：接口成功率、JVM内存
- 数据库：慢查询数量、连接数
- 系统：CPU负载、磁盘空间
-
常见问题处理：
- 打卡失败：检查Redis连接池配置
- 审批延迟：优化Activiti工作流引擎线程池
- 数据不同步：验证MySQL主从复制状态
6. 项目总结与扩展思考
在实际部署到某高校后，系统取得了显著效果：
- 每日打卡率从78%提升至99.5%
- 请假审批时间平均缩短至2小时内
- 疫情溯源效率提升60%
几个值得分享的经验：
- 定位校验要适度：初期过于严格导致偏远校区GPS信号差的学生无法打卡
- 审批流要灵活：疫情期间需支持"特事特办"的绿色通道
- 数据看板要实时：校领导特别关注当日异常体温预警
未来可扩展方向：
- 对接校园一卡通系统实现自动身份核验
- 增加微信消息推送提醒未打卡学生
- 引入机器学习预测疫情传播风险