每年到毕设选题的高峰期，总会有同学问我同一个问题：“这个毕业设计题目是不是过时了？”问得最频繁的就是手里这套——SSM+Java 2026年毕设全球新冠疫情实时统计系统app【源码+论文】。我第一次接触这个题目的时候也犹豫过，疫情相关的话题热度确实不比当年，但等我真正把源码和配套论文从头到尾过了一遍，反而觉得这是个被明显低估的选题。它表面上是统计疫情数据，实际上把“外部数据抓取→数据清洗→关系型存储→后端接口→移动端展示”整条链路完整地串了起来，把这个外壳换成别的业务，几乎就是一套标准的实时监控系统。这篇文章我就按实际做项目的顺序，拆解选型逻辑、数据源处理、SSM接口设计、App端实现、论文答辩这五个关键环节，给正在做这个题、或者做同类实时统计类毕设的同学一份可以照着走的地图。
1. 全球疫情统计这个题放到2026年，还值不值得做？三条理由讲清楚
1.1 它不靠新意取胜，靠的是业务闭环完整
先给结论：这个题不属于“热门”，但绝对属于“扛得住答辩”的选题。
第一条理由是数据真实。毕设最怕自己做一套看起来能用的系统，实际上全是造数据和假逻辑。疫情统计则不同，有大量公开的历史数据和时间序列，系统里展示的全球趋势、各国排名、每日增量，都可以去真实数据源核对。有真实数据做支撑，论文里的功能测试、结果分析都有实际对象，而不是空对空。
第二条理由是维度足够多。一个全球统计系统天然包含三类维度：
- 区域维度：全球总览、按大洲聚合、按国家排行；
- 时间维度：每日新增、累计曲线、同比环比；
- 业务维度：确诊、治愈、死亡、重症等指标，不同数据源的口径还不同。
这意味着从数据库表设计到接口设计都有得写，不会出现“一个表加几个页面就交差”的情况。
第三条理由它逼着你前后端打通。现在很多毕设做“管理系统”，实际上只是用浏览器操作数据库。但这个题目天然带有“对外提供数据服务”的味道，后端必须提供标准接口给App端调用，你得真正去解决RESTful设计、统一返回体、分页参数、超时处理这些真实开发中才会遇到的问题。等你做完这个项目，再去面Java开发岗，讲项目经历的时候会顺很多。
1.2 用了SSM不等于落后，关键看你会不会讲
很多学生对SSM三个字母有顾虑，觉得2026年了还用什么Spring+SpringMVC+MyBatis，应该直接上Spring Boot。
我不这么看。毕业设计的核心目的不是给评委展示新技术，而是让评委看到你对软件工程基本结构的理解。SSM的好处恰恰在于它“手工感”很强，没有自动配置帮你藏东西，Controller层、Service层、Mapper层的边界非常明确：
- Spring负责管理Service和Mapper等Bean的依赖关系；
- SpringMVC负责HTTP请求的接收、路由和响应序列化；
- MyBatis负责把SQL与Java对象映射起来。
你用Spring Boot当然也能实现同样功能，但很多概念——比如请求是怎么进到Controller的、事务注解在哪个层面生效、Mapper代理是怎么生成的——都会被自动配置的“黑盒”掩盖掉。SSM反而逼着你把分层的道理讲清楚，论文里能画出一张清晰的三层结构图，答辩时面对“你怎么做解耦”这类问题会答得比直接背Spring Boot注解扎实。
如果导师允许自由选型，我个人建议还是先按SSM思路写一遍，再用Spring Boot重构一版，这样论文里还能多一段“系统优化与演进”的对比，答辩反而更好讲。
1.3 哪些同学适合选这个方向
这个题比较适合下面几类人：
- 后端基础一般，想通过一个完整项目把Java Web链路串起来的人；
- 不擅长纯算法题，但愿意写代码也愿意写文档的人；
- 想做数据可视化，但又不想只做静态图表的人。
它锻炼的核心能力也很清楚：外部数据源对接能力、数据库建模能力、接口设计能力和移动端联调能力。这几项拿到任何Java开发岗面试里，都能直接写进项目经历。
2. “实时”这两个字的核心不在后端，在数据源：抓取、清洗、入库
2.1 数据源怎么取舍：别自己造假，也别无脑接第三方API
很多同学拿到题的第一步是找免费的疫情API网站。但第三方API有两个硬伤：一是接口经常变，字段名说改就改；二是很多免费接口不稳定，答辩现场前端拿不到数据，非常尴尬。
我推荐把主数据源放在GitHub上的开放数据仓库。理由很实际：开源仓库长期有人维护，格式稳定，普遍采用CSV文件按天更新，比如高校和科研机构维护的COVID-19历史数据仓库、包含疫苗与检测数据的开源数据集等。CSV是最不挑工具的数据格式，Java解析起来很简单。你可以把远程文件下载到本地保存，就算答辩时外部网络出问题，本地缓存的数据也足够演示。
关于主数据源和补充数据源的搭配：如果只看全球总览和各国趋势，一个主数据源完全够用；如果论文想写得更丰富，比如加疫苗接种统计，再补一个补充数据源即可。
2.2 定时抓取任务怎么落：Quartz + HttpClient + CSV解析
后端用定时任务定时拉数据。我用Quartz，因为它和Spring整合很成熟，配置一个JobDetail加Trigger就能定义每小时或每天触发一次。
核心流程分三步：
- 用HttpClient下载CSV文件到临时目录；
- 用OpenCSV读取并转为Java对象；
- 在同一个事务里完成增量更新或全量覆盖。
这里贴一个最简化的抓取代码结构：
public class DataFetchJob implements Job { @Override public void execute(JobExecutionContext context) { String url = "https://example-public-data/daily.csv"; try (CloseableHttpClient client = HttpClients.createDefault()) { HttpGet request = new HttpGet(url); try (CloseableHttpResponse response = client.execute(request)) { InputStream in = response.getEntity().getContent(); List<CovidRecord> records = CsvParser.parse(in); statisticService.saveOrUpdate(records); } } catch (Exception e) { log.error("数据抓取失败", e); alarmService.send("抓取任务异常：" + e.getMessage()); } } }提醒一点：原始CSV文件到了后期会累积很大，接口没必要每次全量读全库。一个稳定的做法是把stat_date字段作为唯一键，先查库里已有的最大日期，只处理新增日期的数据；如果拉下来的文件里max date和库里一致，直接跳过，避免重复写入。
2.3 数据清洗才是这个项目最花时间的环节
刚拿到数据你会崩溃，因为不同机构对国家的英文名写法五花八门。比如同一个国家可能叫“Mainland China”“China”“China (mainland)”，另一个国家可能叫“US”“United States”“America”。如果直接入库，排行榜上同一个国家会裂成好几条，整个系统看起来就是错的。
清洗环节建议维护一张别名表：
| 标准国家名 | 别名1 | 别名2 | 标准代码 |
|---|---|---|---|
| China | Mainland China | China (mainland) | CN |
| United States | US | America | US |
| United Kingdom | UK | Great Britain | GB |
清洗规则我按优先级处理：
- 先去空格、统一大小写；
- 用别名表做字符串匹配；
- 匹配不到的归入“未知”并写日志人工核对，而不是默认丢弃；
- 缺失字段保留null，不要用0填充。
第4点很多同学忽略。用0去填充缺失值，画出来的图会把“没有数据”和“真的是0”混在一起，答辩时被评委追问一下很容易露馅。
2.4 入库用MyBatis批量操作，别一条条insert
默认在for循环里一条条insert，数据量一上来会非常慢，几万条数据可能跑十几分钟，定时任务根本跑不起来。正确做法是让MyBatis走批量会话。批量SQL的Mapper写法：
<insert id="batchInsert" parameterType="list"> INSERT INTO global_stats (country_code, country_name, confirmed_cases, cured_cases, dead_cases, stat_date, update_time) VALUES <foreach collection="list" item="item" separator=","> (#{item.countryCode}, #{item.countryName}, #{item.confirmed}, #{item.cured}, #{item.dead}, #{item.statDate}, #{item.updateTime}) </foreach> </insert>这里有一个时区问题值得单说：stat_date存日期，update_time存更新时间，建议统一存UTC时间，App端展示时再按用户时区转换。如果数据库和Java服务用的时区不一致，会出现日期差一天的隐蔽bug，而且这种bug很难查，因为它只在特定时间窗口出现。
3. SSM后端接口怎么设计，App端拿到的数据才会又快又稳
3.1 Controller、Service、Mapper三层的职责边界
SSM项目最容易写坏的地方是Controller里写SQL、Service里堆查询、Mapper里塞业务判断。这个题涉及定时任务、缓存、外部数据源，更要提前把分层边界定清楚：
- Controller层：只做参数接收、简单校验和返回封装，不碰数据逻辑；
- Service层：负责业务编排，包括查缓存还是查库、更新缓存、清洗逻辑调度；
- Mapper层：只负责SQL和对象映射，不写if/else业务判断。
这样做最大的好处是可以单独测试。我在写这个项目时，Service层每个方法都能用单元测试跑一遍，Controller层的问题则通过MockMvc做接口测试。一个完整的测试用例跑完，答辩时基本不会被简单问题问倒。
3.2 统一返回体和错误码是App联调的基础
App端和后端虽然是同一个人开发的，但接口格式不统一照样会乱。我固定了一套返回结构：
{ "code": 200, "message": "success", "data": { "totalConfirmed": 7000000, "totalCured": 6100000, "totalDead": 700000, "lastUpdateTime": "2026-04-12 06:30:00" } }错误码统一约定：
- 200：请求成功；
- 400：参数错误，包括缺参数或日期格式不对；
- 401：未登录或token过期；
- 404：请求的资源不存在；
- 500：服务器内部错误。
App端只检查code，按message提示用户就行。这里重要性容易被低估：统一错误码之后，线上排查问题能五分钟内定位，不用翻大量日志。
3.3 缓存策略：所谓“实时”系统，其实做了很多“不实时”的设计
做实时统计系统，第一步要认清事实：你的数据源更新频率是小时级，所以后端接口的“实时”指的是快速响应，而不是秒级和数据库同步。
我在Service层加了一层内存缓存。实现不一定要用Redis，Caffeine或者最简单的ConcurrentHashMap就够了：
- key例如“overview:global”对应全球总览；
- key“trend:CN:30”对应中国30天趋势；
- key“ranking:countries”对应国家排行榜。
缓存刷新时机有两个选择：定时任务更新数据后主动刷新，或者设置一个较短的过期时间让数据自然过期。我更推荐“主动刷新+兜底过期”的组合。主动刷新能保证用户随时拿到的是最新数据，兜底过期防止定时任务出异常后缓存永久不更新。
接口返回时还要带上lastUpdateTime字段，App端在页面上明确显示“数据更新于xx时间”。这既是一个正确的产品细节，也是给开发留退路——用户能看到数据并非秒级实时，但系统没有骗人。
3.4 查询优化：索引、分组取最新、排行榜聚合
核心表建立之后，联合唯一索引是必须的：
CREATE TABLE global_stats ( id BIGINT AUTO_INCREMENT PRIMARY KEY, country_code VARCHAR(16) NOT NULL, country_name VARCHAR(64) NOT NULL, confirmed_cases BIGINT NOT NULL DEFAULT 0, cured_cases BIGINT NOT NULL DEFAULT 0, dead_cases BIGINT NOT NULL DEFAULT 0, stat_date DATE NOT NULL, update_time DATETIME NOT NULL, data_source VARCHAR(128) DEFAULT NULL, UNIQUE KEY uk_country_date (country_code, stat_date) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;uk_country_date有两个作用：一是防止同一天同一国家重复写入，二是让按国家查时间范围的SQL走索引。
排行榜查询要取每个国家最新日期的数据，在MySQL 8里用窗口函数最干净：
SELECT country_code, country_name, confirmed_cases, dead_cases FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY country_code ORDER BY stat_date DESC) AS rn FROM global_stats ) t WHERE rn = 1 ORDER BY confirmed_cases DESC LIMIT 50;这段SQL固定放在Mapper里，和业务代码分离。实测下来，百万行数据量在索引支撑下响应在几百毫秒级别，加缓存之后基本无感。
4. App端实现：不堆技术，用最稳的方式做出一版能演示的产品
4.1 技术路线：原生、H5还是混合
毕设的App端最怕想太多。有人一上来就说要用Flutter，工具装半天，环境还没配好，时间已经走了一半。
对这个题，我建议按能力分两种情况：
- 如果Android基础一般，推荐“原生外壳+WebView承载H5页面”的混合方案。用Android Studio建原生工程，核心页面加载本地或打包进assets的HTML，图表用ECharts渲染。优点是开发速度快，同一个HTML调试方便，答辩时打开手机就能演示。
- 如果对Android原生比较熟，就用原生活动加Retrofit网络层加MPAndroidChart图表库，做出来的效果更“像App”。
两种方案各有取舍。混合方案代码量小，但界面容易被看出是网页；原生方案观感好，但写图表的代码量会大一些。我一般建议用第一种做保底，因为上线速度快、风险低，任何功能调整只需改HTML。
4.2 核心页面和图表怎么实现
App端核心功能可以收敛成三个页面：
- 首页全球总览：全球累计确诊、累计治愈、累计死亡、数据更新时间，配一个每日新增趋势折线图；
- 国家排行页：列表展示各国数据，支持排序和搜索，点击进详情；
- 国家详情页：展示该国历史趋势曲线，并对比全球平均情况。
图表实现上我倾向ECharts，在WebView里渲染非常方便，内置折线、柱状、饼图、地图等多种类型，后端返回时间序列后构造option的series即可：
$.getJSON('/api/trend?countryCode=CN&days=30', function (res) { if (res.code !== 200) return; var dates = res.data.map(function (item) { return item.date; }); var confirmed = res.data.map(function (item) { return item.confirmed; }); myChart.setOption({ xAxis: { type: 'category', data: dates }, yAxis: { type: 'value' }, series: [{ type: 'line', data: confirmed, areaStyle: {} }] }); });在这个方案下，后端接口和前端联调很顺畅。但要注意，WebView访问的是网络接口，不要图省事在assets里硬编码一份过期的JSON，那会让你联调时自己骗自己。
4.3 App联调最容易卡的三个点
第一个是模拟器访问本机。Android模拟器里访问电脑的localhost要写10.0.2.2，很多同学直接写localhost，一直连不上。真机调试要用电脑的局域网IP，手机和电脑必须在同一WiFi下，后端防火墙还要放行对应端口。
第二个是跨域和超时。如果App端页面是WebView加载远程页面，而接口是另一个域名，后端必须配置跨域。建议在SpringMVC层配置全局CORS，不要每个Controller单独处理。
第三个是图表在低配手机上卡顿。趋势数据如果一次返回一整年365天的颗粒度，几百个点虽然能画，但明显掉帧。更好的做法是后端做降采样——超过60个点就按“每N天取一个点+最后一天必须保留”的策略聚合，图表看不出太大差别，性能却提升明显。这个细节很能体现工程思维，答辩时可以专门提一句。
5. 论文、源码、答辩三件套：让项目真正交得出去
5.1 论文结构怎么搭：顺着开发流程走，别照着模板硬套
论文不是最后才写的，而是和开发同步生长的。这个题的论文大纲建议直接按系统开发逻辑展开：
- 绪论：选题背景与意义、国内外研究现状、主要工作；
- 相关技术概述：SSM框架、Android技术、数据可视化、定时任务；
- 系统需求分析：功能性需求（总览、排行、详情、登录）和非功能性需求（性能、安全、可维护性）；
- 系统设计：总体架构、功能模块、数据库设计；
- 系统实现：各模块核心代码和效果描述；
- 系统测试：功能测试用例、接口测试、性能测试、结果分析；
- 总结与展望。
这个结构的逻辑是背景→技术→需求→设计→实现→验证，是一条完整的工程链路。很多论文被答辩老师挑毛病，不是格式问题，而是需求分析里写的功能和系统实现里做的不一致。写论文前，先把自己的功能列表拉出来，确保每个功能在实现章节都有对应的截图和描述。
5.2 源码交付时不能只给一个能跑的工程
源码和论文是配套的，答辩老师不一定会真跑你的代码，但一定会翻你的工程结构和文档。交付包建议至少包含：
- 完整源码工程，含数据库建表SQL脚本和少量初始数据；
- 一份README，写明JDK版本、Maven版本、MySQL版本、部署步骤、测试账号；
- 接口文档，用Swagger或手写接口说明表，标明路径、参数、返回结构；
- App端安装包或演示录屏。
数据库SQL脚本最容易被遗忘。一定要把建库建表语句和样例数据单独放进sql文件，而不是藏在日志或备份目录里。老师拿到项目第一步就是初始化数据库，这一步失败，后面全白搭。
5.3 答辩演示时最加分的三个细节
第一，演示前先展示定时任务日志，证明系统是自动抓取更新的，不是手动填的数据。第二，切换到断网场景或故意传错参数，展示系统有友好的错误提示，这比讲任何技术都更能打动评委。第三，讲数据库优化时，用EXPLAIN展示查询走了哪个索引，再和没索引时的查询做对比，效果非常直观。这三个细节都不需要复杂代码，但能证明系统确实是自己写的，而不是下载跑通。
6. 这套系统里我踩过的五个坑，和它真正能迁移到的地方
6.1 按严重程度排序的踩坑清单
第一个坑是批量插入性能。刚开始图省事在for循环里一条条insert，数据量小的时候没事，一两万条之后定时任务慢得像卡死。改成ExecutorType.BATCH加foreach批量插入后，耗时从十几分钟降到几秒。这个坑几乎每个人都会踩，只要数据量到了就会暴露。
第二个坑是国家名称不一致。清洗环节我花了两天维护别名表，才把排行榜做干净。建议一开始就为所有外部数据源建一套标准国家代码映射表，不要等画图时发现同一个国家有三条线再回头补。
第三个坑是缓存和数据源更新时间错配。上线初期我设置60秒缓存过期，但数据源几小时才更新一次，接口白白增加数据库压力。后来改成“定时任务完成后主动刷新缓存”，接口速度既快又准。核心是理解数据真实更新频率，再做缓存策略。
第四个坑是App模拟器网络。Android模拟器访问宿主机要用10.0.2.2而不是localhost，这是连不上的最常见原因。真机联调则必须用电脑局域网IP，同时注意防火墙端口。
第五个坑是趋势图表卡顿。解决方式是后端采样聚合，最多返回60到90个点，图表平滑，接口数据量也小。
这五个坑整理下来，有一个共同特点：都不是代码写不出来，而是经验层面的问题。同一个项目做完一遍之后，再去处理类似的实时统计系统就会快得多。
6.2 这个项目的真正价值在可迁移
做完这套系统后我最大的感受是：疫情统计只是一个非常合适的外壳，背后这套数据链路换成任何实时统计需求都能跑。比如：
- 电商大促实时销售看板：订单数据每小时同步，展示品类销售排行；
- 电力或气象监控平台：传感器数据定时上报，展示区域曲线和异常告警；
- 物流跟踪系统：每天更新包裹在各节点的数量，展示热力图和趋势。
所以哪怕你只是因为选题库里有这个题才做的，也完全可以在答辩时把它定位成“一套可复用的数据统计与可视化方案”。技术栈不用换，SSM接口、批量写入、缓存和聚合查询全部可以复用。
我自己带这个项目最大的体会是：毕设不是在拼技术多新，而是拼你能不能在有限时间里跑通一条完整数据链路，并用论文把整个过程讲清楚。如果你正在做这个题，照着数据源、接口、缓存、App、论文这条路线一步步来，稳过没问题。遇到具体问题欢迎评论区聊，看到都会回。
