高校疫情防控专题网站毕设实战：从需求分析到答辩全流程指南-代码聚汇网

高校疫情防控专题网站毕设实战：从需求分析到答辩全流程指南

Spring Boot毕业设计疫情防控专题网站

|难度：普通|阅读约 30 分钟

作为经历过完整毕业设计全流程的过来人，看到“安康学院新型冠状病毒肺炎疫情防控专题网站”这个题目，第一反应是：这是一个兼顾实用价值、技术含量和时代背景的典型毕业设计选题。它不像“图书管理系统”“购物网站”那样千篇一律，而是有真实的使用场景——高校疫情防控需要信息发布、健康数据收集、政策宣传等一整套线上支撑。这也是为什么很多学校会把类似的选题推荐给计算机专业学生，它既能覆盖前端展示、后端逻辑、数据库设计这些基本功，又能在论文里写出清晰的需求分析和系统架构，答辩时也容易讲清楚“为什么做”“做了什么”“效果如何”。

这篇博文我就围绕这个题目，把从选题拆解、需求分析、技术选型，到功能设计、数据库建模、核心模块实现，再到论文写作、PPT制作和演示视频录制这一整条链路，完整地捋一遍。无论你是拿了类似题目的应届生，还是想了解高校专题类网站怎么做的开发者，顺着这套思路走，基本能把项目从头到尾落地清楚。

1. 选题拆解与整体设计思路

1.1 这个题目的真实需求是什么

先别急着打开IDE写代码，第一步应该是把题目里的需求边界划清楚。“疫情防控专题网站”听起来简单，但落到高校场景，实际包含的信息维度不少：

信息发布层面：学校需要向师生发布防疫通知、政策文件、防控指南、就诊指引。这些内容要有分类、有检索、有置顶能力。
数据收集层面：日常健康上报（体温、行程、健康码状态）、返校申请、异常情况登记。这部分涉及用户身份、数据校验和统计汇总。
事务处理层面：师生提交健康数据后，辅导员或校医院需要查看、审核、导出统计。
宣传展示层面：防控知识科普、校内防疫动态、辟谣信息等，需要以图文甚至视频形式呈现。

所以这个网站的定位不是单页展示站，而是“内容管理+数据上报+后台管理”三位一体的业务系统。理解了这一点，后续的模块划分和数据库设计就不会跑偏。

1.2 架构选型：为什么优先考虑单体应用

毕设场景和商业项目有本质区别。商业项目要考虑高并发、微服务拆分、容器编排，但毕设的评分重点是逻辑完整性、知识点覆盖和文档规范度。所以我个人强烈建议：优先采用单体架构，前后端根据个人熟悉程度决定是否分离。

如果你Java基础扎实，可以直接用Spring Boot + Thymeleaf做服务端渲染，减少前后端联调成本；如果你对Vue或React更熟，就用Spring Boot + Vue做前后端分离。两者都是合理方案，关键看哪个你在答辩时“讲得清、改得动”。

我见过太多人为追求时髦，在毕设里强行上微服务、Redis缓存、消息队列，结果代码写得一塌糊涂，答辩被老师追问两句就卡壳。老老实实把CRUD写清楚、把权限控制做出来、把数据统计展示明白，比什么都强。

1.3 核心功能模块划分

在前述需求分析基础上，这个项目可以拆成以下几个模块：

前台门户模块：包括公告通知列表页、新闻详情页、防控指南页面、健康上报入口、个人上报记录查询。
用户系统模块：学生、教职工、管理员三类角色，提供注册（或由管理员导入）、登录、密码重置、个人资料维护。
每日健康上报模块：体温、是否咳嗽、是否接触高风险地区人员、当前所在地、健康码颜色、行程备注。
后台管理模块：公告内容管理、用户管理、上报记录审核与导出、统计图表展示。
数据统计模块：用ECharts展示每日上报人数趋势、异常体温分布、各院系上报率等。

这些模块加在一起，就是一个“麻雀虽小，五脏俱全”的信息管理系统，用来支撑毕业论文的核心章节绰绰有余。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 数据库设计与关键技术选型

2.1 数据表结构这样设计最省心

搞毕设最忌讳一上来就建三四十张表，表多了关联复杂，写代码时把自己绕晕。针对这个项目，我建议控制在6到8张表左右，既覆盖核心需求，又不会自找麻烦。

以MySQL为例，核心表可以设计如下：

用户表（t_user）

字段名	类型	说明
id	bigint 主键	自增主键
user_name	varchar	登录用户名
password	varchar	MD5加密后的密码
real_name	varchar	真实姓名
role	tinyint	1-学生，2-教职工，3-管理员
college	varchar	所属院系
student_no	varchar	学号（可选）
create_time	datetime	创建时间

公告表（t_notice）

字段名	类型	说明
id	bigint 主键	自增主键
title	varchar	标题
content	text	正文内容
category	varchar	分类，如通知、政策、科普
is_top	tinyint	是否置顶
create_time	datetime	发布时间
publisher	varchar	发布人

健康上报记录表（t_health_report）

字段名	类型	说明
id	bigint 主键	自增主键
user_id	bigint	关联用户表
report_date	date	上报日期
temperature	decimal(4,1)	体温
is_cough	tinyint	是否咳嗽
is_contact	tinyint	是否接触高风险人员
health_code	varchar	健康码颜色
location	varchar	当前所在地
remark	varchar	备注
create_time	datetime	提交时间

这里有个小细节：上报记录要加唯一索引（user_id, report_date），防止同一个人同一天重复提交或重复插入数据。

除这三张主表外，建议再建一张管理员操作日志表，记录后台的关键操作。写论文时“系统安全性设计”一节就有内容可写了。

2.2 框架选型与版本搭配

我推荐的组合是：Spring Boot 2.x + MyBatis-Plus + MySQL 8 + Vue 2（可选）+ ECharts。这套组合文档丰富、社区活跃，出问题网上随便搜都有答案。

Spring Boot 2.5+ 简化配置，内嵌Tomcat，裸跑就能起服务。
MyBatis-Plus 比原生MyBatis省掉大量XML，内置CRUD方法，分页插件也很香，写代码效率提升一个档次。
MySQL 8 是当前主流，注意驱动和时区配置（serverTimezone=Asia/Shanghai），否则容易踩连接报错。
Vue 2 + Element UI 适合做后台管理界面，但如果你没学过Vue，用Thymeleaf + Bootstrap同样能实现漂亮的前台。

2.3 环境搭建踩坑清单

环境这块很多同学栽跟头，我列几个最容易出问题的地方：

MySQL 8与Spring Boot连接驱动：com.mysql.cj.jdbc.Driver 比老的 com.mysql.jdbc.Driver 多了个cj，千万别写错。
端口冲突：Spring Boot默认8080，如果被占用就 server.port=8081 改掉。
IDEA与Lombok插件的兼容性：用了 @Data 注解就记得装Lombok插件，否则编译直接报错找变量。
Maven依赖下载慢：把镜像改成阿里云仓库，地址在settings.xml里配好。

这些话说白了都是入门级的坑，但每年都有一批人卡在这些地方，提前排查能省出大把写论文的时间。

3. 核心模块实现要点与实操记录

3.1 登录模块：权限控制这样写不混乱

这个项目有三类角色，所以登录后的首页跳转、菜单展示、接口访问都要做角色区分。我的做法是：

用户登录成功后，把用户ID和角色存进Session，同时写一个拦截器，针对 /admin/** 路径做管理员权限校验，没有权限直接重定向到403页面。

贴一段核心拦截器逻辑（Spring Boot + Spring MVC方式）：

java复制public class AdminInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        User user = (User) request.getSession().getAttribute("loginUser");
        if (user == null) {
            response.sendRedirect("/login");
            return false;
        }
        if (user.getRole() != 3) { // 3代表管理员
            response.sendRedirect("/noPermission");
            return false;
        }
        return true;
    }
}

然后在WebConfig里注册：

java复制@Override
public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(new AdminInterceptor())
            .addPathPatterns("/admin/**")
            .excludePathPatterns("/admin/login", "/admin/css/**", "/admin/js/**");
}

这里要提醒一句：前端页面隐藏菜单不算权限控制，真正要拦截的是后端接口。有些同学只做了按钮隐藏，结果别人直接输URL照样能进后台，这种低级漏洞答辩时特别容易被点出来。

如果用了Spring Security或Shiro，代码会更优雅，但学习成本高。毕设求稳的话，拦截器完全够用，论文里也可以写清楚这一设计逻辑。

3.2 每日健康上报模块：防重复提交的实现

健康上报是系统的核心业务，常态下每人每天只能提交一条记录，所以除了数据库加唯一索引，后端也要做判断。

核心逻辑用一句话描述：先根据 user_id 和 today 查询记录，查到了就提示“今日已上报”，没查到才执行 insert。

java复制public R submitReport(HealthReport report) {
    User user = getLoginUser();
    report.setUserId(user.getId());
    report.setReportDate(new Date());
    Long count = healthReportMapper.selectCount(
            new LambdaQueryWrapper<HealthReport>()
                    .eq(HealthReport::getUserId, user.getId())
                    .eq(HealthReport::getReportDate, report.getReportDate()));
    if (count > 0) {
        return R.error("今日已提交，请勿重复上报");
    }
    healthReportMapper.insert(report);
    return R.ok("上报成功");
}

这段代码看着简单，但整个模块的稳定性全靠它撑。如果你把查重逻辑放到Service层而MySQL没有唯一索引，并发情况下还是有可能插入两条重复记录。两个手段一起上，才能确保数据不出问题。

3.3 数据统计模块：ECharts这样接入

“每日上报人数趋势”和“各院系上报率”是论文和PPT里的亮点功能，建议用ECharts画图。

后端返回JSON格式数据，比如：

json复制{
  "dates": ["2024-06-01", "2024-06-02", "2024-06-03"],
  "counts": [4521, 4680, 4752]
}

前端用Axios请求接口，渲染折线图：

javascript复制axios.get('/api/report/trend').then(res => {
    const chart = echarts.init(document.getElementById('chart'));
    chart.setOption({
        tooltip: { trigger: 'axis' },
        xAxis: { type: 'category', data: res.data.dates },
        yAxis: { type: 'value' },
        series: [{ type: 'line', data: res.data.counts, smooth: true }]
    });
});

这里想多啰嗦两句：图表对应的SQL不要写死，最好支持按时间范围筛选。论文的需求分析里写“系统应支持历史数据可视化分析”，答辩时你就可以打开页面现场选日期、切图表、讲实现逻辑，整个项目档次马上就上来了。

3.4 公告发布与管理模块

公告模块就是标准CRUD，但有两个容易遗漏的细节：置顶功能和浏览量统计。

置顶用 is_top 字段实现，前台列表 ORDER BY is_top DESC, create_time DESC 即可。浏览量就一个 view_count 字段，详情页每次访问加1。虽是简单逻辑，但能让网站看起来更真实。

后台公告列表建议加一个“发布/下线”状态，不要直接删数据。彻底删除会导致历史动态缺失，后面写“系统测试”时不好构造数据。保留下线状态这个字段，既能控制前台展示，又保住数据完整性。

4. 毕业论文结构与答辩PPT的衔接

4.1 论文章节这样安排最稳妥

这篇论文写起来其实有天然优势，因为“疫情防控专题网站”的需求来源和业务逻辑都很好描述。我建议按六章结构写：

第一章绪论：写背景意义（高校防疫的信息化需求）、国内外研究现状（可以泛泛描述线上信息平台的应用趋势）、主要工作与结构安排。

第二章相关技术介绍：Spring Boot、MyBatis-Plus、MySQL、Vue/ECharts等。这一章是凑篇幅和展示知识储备的地方，但不要复制官网介绍，要用自己的话简练描述并说明“为什么选它”。

第三章系统需求分析：功能性需求（角色用例图）、非功能需求（性能、安全、易用性）、可行性分析（技术、经济、操作）。

第四章系统设计：总体架构图、功能模块图、数据库ER图、关键表结构字段说明。

第五章系统实现：环境配置、关键模块的代码片段+页面截图+功能说明。这里是最容易拿到工作量的章节，每个功能模块配两三张截图，写起来飞快。

第六章系统测试：功能测试用例表（测试项、测试步骤、预期结果、实测结果）、性能测试简述（可以用JMeter简单压一下登录接口）。

4.2 答辩PPT怎么做出亮点

PPT控制在15到20页，结构照这条线走：

封面（题目+姓名+学号+指导教师）
目录页
选题背景与意义（放2-3条痛点即可，不用长篇大论）
核心功能总览（一张功能结构图）
技术选型及理由（一张对比表格）
数据库设计（放ER图+核心表）
系统核心界面展示（前台首页、健康上报、统计图表、后台管理）
关键技术实现说明（选1-2个有亮点的讲，比如防重复上报、权限拦截）
系统测试结果（表格呈现）
总结与展望

答辩最忌讳照着PPT念代码。代码贴一张截图，重点讲“为什么这么实现”“遇到什么问题怎么解决的”，比如“这里为了防止同一天重复上报，我在数据库加了唯一索引，同时后端也做了校验”，这种话一出口，评委就知道这个项目确实是你自己做的。

4.3 演示视频录制：别忽略这个交付件

这个题目附带视频演示，很多同学录的时候不走心，画面晃动、鼠标乱飞、步骤跳来跳去，结果老师看起来体验极差。我的建议是：用OBS录屏，分辨率调1920x1080，鼠标指针加大，提前写好脚本。

一个靠谱的演示流程是：

打开项目，展示前台首页
注册一个学生账号/登录学生账号
提交一次健康上报
切换管理员账号，进入后台
查看今日上报人数统计、公告管理
演示权限拦截（普通用户访问/admin被拒绝）
展示系统测试过程中录制的异常场景

总共控制在5到8分钟，页面切换要慢、要稳，录完剪辑时加上两秒的过场字幕，比如“学生端演示”“管理端演示”，整体质感会好很多。视频最后提交前，再检查一遍分辨率是否清晰、声音是否正常，别到答辩才发现打不开文件。

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

这节内容是实打实踩坑总结，建议记下来，做项目时能省很多时间。

5.1 数据库相关高频问题

中文乱码：MySQL连接URL加 characterEncoding=utf8，同时保证表结构是 utf8mb4。还有一个常被忽略的地方——IDEA控制台输出乱码是编码设置问题，和数据库无关，别混在一起排查。
连不上数据库：先 ping MySQL端口是否能通，再看Spring Boot配置里的url、用户名、密码。最容易翻车的是时区没配，报错信息带 Server time zone 字样，解决方法是URL后面加 serverTimezone=Asia/Shanghai。
表字段与实体类映射不上：MyBatis-Plus默认开启驼峰转换，如果数据库字段是 user_name，实体字段写成 userName，正常情况下能自动映射。如果不行，检查 map-underscore-to-camel-case 配置是否开启。

5.2 前端页面问题

跨域问题在前后端分离项目里最常见。Spring Boot后端加个CORS配置就行：

java复制@Configuration
public class CorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOriginPattern("*");
        config.addAllowedHeader("*");
        config.addAllowedMethod("*");
        config.setAllowCredentials(true);
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

这里要澄清一个误区：加了 @CrossOrigin 注解只对单个Controller有效，全局CORS用Filter更靠谱，而且注意 allowCredentials(true) 时不能用 * 作为允许来源，会冲突。

5.3 历史数据造数很关键

演示和测试阶段，数据库里应造出一周甚至一个月的模拟上报数据，这样统计图表才有展示内容。最简单的办法是用SQL循环插入。用存储过程或者直接在Navicat里执行多行INSERT都能实现。数据量不一定大，但日期要连续、数值要自然，比如大部分人体温在36.2到36.7之间，偶尔出现一个37.3以上的异常，这样展示“异常用户筛查”功能时才有东西可看。

5.4 关于部署遇到的问题

毕设答辩现场一般需要直接演示系统，最稳妥的部署方式是本地IDEA直接跑。但如果老师要求在服务器上跑，或者需要提交一个可运行的包，建议执行 mvn clean package 打成jar包，再用 java -jar 启动。

打包时有个常见坑：前端资源包含在Spring Boot项目中时，一定要确认 application.yml 里静态资源路径没被拦截器误拦。很多拦截器把 /** 拦截了，导致CSS样式加载不出来，页面异常难看。

6. 从项目到毕设：心态与时间安排的建议

这是我个人最想分享的一段经验。毕设周期通常有几个月，但大部分人都是前松后紧，最后一个月疯狂赶工。如果你正处于规划阶段，我建议把时间按三块分配：第一周做需求分析和数据库设计，第二周到第四周写代码、测功能，最后两周写论文、做PPT、录视频。数据库设计这一步千万别省，表结构设计不合理，后面代码返工量是成倍的。

写代码的时候要养成顺手写注释的习惯，不用多，关键逻辑处三五行就行。论文第五章直接能复用这些注释扩写，省得最后对着代码回忆“这段是干嘛的”。

遇到不会的问题，别死磕超过一小时。Spring Boot的问题百分之八十是配置问题，把报错信息完整复制到搜索框里搜一下，基本都能找到答案。踩坑的整个过程，恰恰是答辩时最值得讲的实战收获。

一个额外的小建议：找同学互相交叉测试系统。自己测的时候容易“滤镜过重”，觉得哪都好；让同学帮忙点点，往往能发现隐藏的bug或体验问题。把这个测试过程记录下来，对应到论文“系统测试”章节，比编造测试用例有说服力得多。

这个专题网站做完后，如果还有余力，可以想想怎么扩展：比如接入学校的统一身份认证、增加消息提醒功能、导出Excel健康报表等。这些扩展点在论文“展望”部分写一下，整个课题的完整性会更好。但前提是核心功能已经稳定，别为了加功能把自己拖进泥潭。

健康上报、公告发布、数据统计、权限管理，这四块是项目的命根子。核心四块撑住，其他都是锦上添花。祝你的毕设顺利通过。