
1. 项目背景与核心需求2020年以来的全球公共卫生事件让健康监测系统成为刚需。我去年为某高校开发的这套疫情打卡系统核心解决三个痛点师生每日健康数据采集困难、人工统计效率低下、异常情况响应滞后。系统采用SpringBootVue的前后端分离架构MySQL作为数据持久层实现了从数据采集到风险预警的全流程自动化。这个毕设选题的巧妙之处在于既符合当下社会需求又能完整展示全栈开发能力。系统包含用户端微信小程序Vue网页、管理后台、数据看板三大模块完整覆盖了从需求分析到部署上线的软件开发全生命周期。2. 技术栈选型解析2.1 为什么选择SpringBoot后端选用SpringBoot 2.7.3版本非最新的3.x主要考虑三点自动配置特性让疫情这种需要快速响应的项目能立即启动内置Tomcat简化部署配合Actuator端点方便监控系统健康状态事务管理采用Transactional默认自动提交适合高频打卡场景特别提醒SpringBoot与MyBatis整合时分页插件PageHelper的依赖版本要特别注意。我们遇到过5.3.0版本与SpringBoot 2.7.x的兼容性问题最终锁定5.2.0版本稳定运行。2.2 Vue3的组合式API优势前端选用Vue3Element Plus相比Vue2有明显提升组合式API让健康码状态管理更清晰Teleport组件优化了弹窗式疫情通知的DOM结构用Vue Router的路径参数实现地区疫情等级传递踩坑记录尝试用vue-fullscreen插件实现全屏地图展示疫情分布时发现与Element Plus的弹窗组件存在z-index冲突最终通过动态修改transition样式解决。2.3 MySQL设计要点数据库采用MySQL 8.0关键设计包括用户健康表添加spatial索引支持地理位置查询打卡记录表使用分区表按日期range分区建立触发器自动更新学生所在班级的风险等级特别注意timestamp字段的时区问题曾导致跨时区部署时统计异常最终统一采用UTC时间并在业务层转换。3. 核心功能实现细节3.1 健康码状态机设计系统最复杂的业务逻辑是健康码状态转换// 状态枚举定义 public enum HealthCodeStatus { GREEN(1), YELLOW(2), RED(3); // 状态转换规则 public static HealthCodeStatus transition(HealthReport report) { if(report.getTemperature() 37.3) return RED; if(report.getContactRisk()) return YELLOW; return GREEN; } }重要提示状态变更需要同步通知班主任和校医我们采用Spring事件机制实现解耦EventListener public void handleCodeChange(HealthCodeChangeEvent event) { wechatService.pushAlert(event.getUserId(), event.getNewStatus()); }3.2 前后端交互关键点跨域解决方案采用Nginx反向代理而非CrossOrigin注解因为需要支持Cookie传输文件上传使用阿里云OSS直传方案前端获取临时凭证实时数据推送WebSocket协议实现风险地区实时预警接口设计示例// Vue组件中调用打卡接口 const submitHealthReport async () { try { await axios.post(/api/health/report, { temperature: 36.5, location: store.getters.currentLocation, symptoms: [] }, { headers: { X-Requested-With: XMLHttpRequest } }); } catch (err) { ElMessage.error(提交失败 err.response.data.message); } }4. 部署与性能优化4.1 多环境部署方案开发环境Docker Compose一键启动services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ${DB_PASSWORD} volumes: - ./mysql/init.sql:/docker-entrypoint-initdb.d/init.sql生产环境前端Nginx容器化部署开启gzip和Brotli压缩后端JAR包配合Jenkins CI/CD流水线数据库阿里云RDS主从架构4.2 性能优化实战热点数据缓存用Redis缓存班级风险等级TTL设置15分钟定时任务优化改用Elastic-Job替代Scheduled解决分布式环境重复执行问题SQL优化对日报统计查询添加covering index压力测试结果单机配置4核8G可支撑5000人同时打卡95%的API响应时间200ms使用JMeter模拟峰值流量时发现MySQL连接池瓶颈调整HikariCP配置后解决5. 论文写作要点技术类毕设论文要突出以下几点创新性我们引入了LBS地理围栏技术自动校验打卡位置真实性完整性系统包含需求分析、架构设计、安全方案防SQL注入/XSS、测试用例实用性已实际部署在某高校运行6个月收集真实用户反馈特别提醒论文中的架构图建议使用Draw.io绘制时序图用PlantUML保持专业风格。数据库ER图可直接从MySQL Workbench导出。6. 常见问题解决方案6.1 微信定位偏差处理实测发现不同手机型号的GPS精度差异导致打卡位置校验失败最终解决方案前端增加手动确认位置按钮后端采用Haversine公式计算两点距离对郊区校区设置500米宽容阈值6.2 并发打卡冲突使用MySQL乐观锁解决UPDATE health_report SET status SUBMITTED WHERE user_id 123 AND date CURDATE() AND version 1;6.3 离线环境适配针对网络条件差的农村校区前端添加PWA离线支持采用localStorage暂存未提交数据实现自动重传机制这套系统开发过程中最大的收获是真实场景下的技术决策必须考虑非理想条件。比如我们原计划使用腾讯地图API但在某些地区访问不稳定最终不得不增加高德地图作为备用方案