SSM+Java+App毕设实战：疫情实时统计系统从零到一完整实现解析

引言：选题三个月后的实话

如果你正在为毕业设计发愁，或者已经在各大源码站翻了不下十页，那这篇关于SSM + Java + App方向毕设系统的长文，应该能帮你省下不少时间。以“全球新冠疫情实时统计系统”为例，它本质上不是一个单纯的CRUD项目，而是一个集"数据采集、定时任务、接口设计、移动端展示、可视化图表"于一体的综合性选题，也是Java后端起家型学生最容易吃透、最容易在答辩时拿出战果的题目。先给大家交个底：这个题目看起来很“应景”，但它真正的难点不在写代码，而在三个方面——如何设计一张靠谱的数据表、如何处理“实时”这个需求边界、如何在论文里把业务价值写清楚。这几年我带学生做毕设，最常见的情况是代码写了两千行，答辩时却讲不出所以然，或者一被问到“为什么用SSM不用Spring Boot”就卡壳。今天这篇文章，我就从选题拆解、技术选型、数据库设计、后端实现、APP端对接、论文输出六个维度，把整个项目的完整走法铺开来讲，保证你从拿到题目到最终演示，心里都有底。

1. 选题拆解：别急着写代码，先搞懂这道题到底在考什么

1.1 题目背后的真实需求

先说结论：考官想要的是一个“数据链路完整”的毕设，而不是一个花里胡哨的APP壳子。网上很多卖源码的版本，首页画个世界地图，点进去全是写死的假数据，答辩老师只要问一句“你这条数据是从哪来的、多久更新一次”，基本就露馅了。所以这个题目的核心价值可以拆成四层：

• 数据层：要解决“全球各个国家/地区的疫情数据从哪来，如何结构化入库”
• 业务层：要解决“按国家查累计确诊、按时间看趋势、按条件排序”这些真实查询需求
• 展示层：要在手机APP上直观呈现数据，而不是让学生用浏览器打开后台管理页面糊弄过去
• 论文层：要把上述工程实践提炼成“系统分析—设计—实现—测试”的完整流程

这个题目用SSM框架来做，其实比Spring Boot更占便宜。为什么？因为SSM的配置繁琐、事务声明、MyBatis映射文件写法，每一个环节都能撑起论文里的一个章节。你用Spring Boot三分钟搭个服务，写论文时反而没有素材。这不是开玩笑，毕业设计的核心目标是“体现工作量与工程规范”，SSM的学习曲线和配置复杂度在这里是加分项，当然前提是你自己确实理解每一条配置是在干什么。

1.2 功能边界与演示策略

很多学生拿到题目后第一反应是“全球疫情，那全世界两百多个国家的数据都要吗”。我的建议是：做全量国家列表，但不追求逐个国家的深度分析。默认展示每个国家的最新一条统计记录，点击进去再展示该国的历史趋势曲线。这样数据量可控（1200个国家或地区×365天），查询响应也快，同时“全量”两个字还能写进论文里当亮点。至于APP端的定位，不需要做成上架应用商店的成品级App，只需要跑通“后端接口 + Android客户端展示”这条链路即可。时间紧张的情况下，用WebView套H5页面也可以，但我后面会推荐一套更稳妥的混合方案。

1.3 适合什么样的人来做

• 大三/大四计算机相关专业，Java课程学过集合、JDBC，但没做过完整项目
• 了解Spring IOC的基本概念，但对Spring MVC的请求流转过程一知半解
• 需要一份既能“写得出代码”又能“写得出论文”的稳妥题目

这个题目最大的优势是套路清晰、扩展性强。哪怕你代码能力弱一点，只要把SSM三大框架的协作关系吃透，再把APP的数据请求逻辑跑通，就足以达到本科毕设的中上水准。

2. 技术选型与系统架构：SSM三件套 + 安卓原生 + 定时任务

2.1 SSM框架的角色分配

先说SSM是什么。SSM是Spring + Spring MVC + MyBatis三个框架的组合简称，在Java后端开发里属于经典的老牌技术栈。三个框架各管一摊，配合起来形成一条完整的请求处理流水线：

框架	扮演角色	核心职责
Spring	容器工厂 / 大管家	管理Service层对象的创建与依赖注入，事务控制、AOP切面
Spring MVC	接待前台 / 路由器	接收浏览器或APP发来的请求，解析URL映射到对应Controller方法
MyBatis	数据库翻译官	把Java对象和SQL语句的映射写好，执行增删改查并返回结果

这套组合的分工逻辑可以打个比方：APP是顾客，Spring MVC是前台服务员，负责按菜单（@RequestMapping）叫号；Spring是后厨主管，负责把食材（Service/DAO对象）分配到各个厨师手里，还管着事务（做菜中途出错就全部退回重做）；MyBatis是采购员，负责按特定格式去仓库（MySQL数据库）取货、送货。理解了这个流程，SSM项目基本就能打通任督二脉。

2.2 App端技术选型：原生Android还是跨平台

题目标题写的是app，但没说必须是原生安卓还是混合开发，这就给了操作空间。我强烈推荐一种组合：Java原生Android工程 作为“壳子” + Retrofit负责HTTP通信 + MPAndroidChart绘制图表。理由有三点：

• 原生Android工程在答辩演示时可以打包成APK现场安装，真实感最强，不会被质疑“你这个不是个网页套皮吗”
• Java是Android的官方开发语言，刚好和你的SSM后端语言统一，知识体系连贯
• 工作量适中：大概需要写5-7个Activity + 2个Adapter + 1个图表实现类，认真做两周能完成

当然，如果你对前端H5更熟，也可以用WebView加载一个自己写的ECharts页面，但这条路我建议不适合作为主方案，因为导师看到地址栏里的“localhost”时，很容易觉得你在用网页模板凑数。

2.3 系统整体架构描述

整个系统的数据流向设计如下：项目部署启动后，后端会有一个定时任务，每天从外部公开数据源拉取一次各国疫情数据，解析后写入MySQL数据库。APP启动时调用后端REST接口，后端从数据库查询最新统计数据，以JSON格式返回，APP本地解析后填充列表、地图和图表。管理员（默认只有一个测试账号）可以通过后台修改部分数据、查看更新日志，这部分用来支撑论文里的“系统管理”功能。

这种“定时拉取+按需查询”的模式，严格来说不属于“实时推送”。真正意义上的实时需要用到WebSocket或消息队列，把服务器数据主动推给客户端。但放到毕设场景里，每天定时更新已经能满足业务描述了，论文里只需要解释一句：“本系统实现的实时统计为近实时模式，通过每日多次定时同步保证较高的数据新鲜度”。这句话既诚实又专业，评委不会在这个点上纠缠。

3. 数据库设计：一张核心统计表，撑起所有页面

3.1 表结构与字段详细说明

数据库设计是整个项目最值得花功夫的地方。我先给出推荐的表结构，然后逐个字段解释原因：

CREATE TABLE country_daily_stats ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', country_code VARCHAR(8) NOT NULL COMMENT '国家二字码，如CN/US/JP', country_name VARCHAR(64) NOT NULL COMMENT '国家名称（中文）', continent VARCHAR(32) DEFAULT NULL COMMENT '所属大洲，如亚洲/欧洲', confirmed INT DEFAULT 0 COMMENT '累计确诊', cure INT DEFAULT 0 COMMENT '累计治愈', death INT DEFAULT 0 COMMENT '累计死亡', confirmed_add INT DEFAULT 0 COMMENT '较昨日新增确诊', death_add INT DEFAULT 0 COMMENT '较昨日新增死亡', update_time DATETIME NOT NULL COMMENT '数据统计时间点', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '入库时间', KEY idx_country_date (country_code, update_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='各国每日疫情统计表';

这张表有两个硬性要求。第一，必须加country_code和update_time的联合索引，因为最频繁的查询场景是“查某个国家的最新数据”，如果没有这个索引，2000万行数据下连最简单的列表页都会卡顿。第二，update_time要用DATETIME而不是VARCHAR存日期字符串，否则后续做时间范围查询时，MySQL无法按时间排序走索引，慢查询会拖垮整个演示过程。

3.2 为什么不用三张表而用一张宽表

很多课程设计喜欢把国家信息单独建一张表，再把每天的统计数据单独建一张表，然后用外键关联。这种规范化设计在学术上是对的，但在这个项目里属于过度设计。因为疫情统计数据的查询模式是“一个国家一行最新记录”，如果拆成两张表，APP端每次加载列表都要做一次JOIN，慢且不好调试。我用的是“宽表冗余”方案：把国家名称、大洲冗余在统计表里，牺牲一点存储空间，换取查询速度和SQL的简洁性。答辩时如果被问到范式问题，可以回答“本系统数据量规模在千万级以下，宽表方案在高频读场景下性能更优”，这是产业界常见的trade-off。

3.3 其他辅助表：用户表与更新日志表

除了核心统计表，还需要设计用户管理相关的表，用于后台登录和日志管理：

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password_md5 VARCHAR(64) NOT NULL, role TINYINT DEFAULT 1 COMMENT '1普通管理员 2超级管理员', status TINYINT DEFAULT 1, last_login_time DATETIME ); CREATE TABLE data_update_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, update_source VARCHAR(255) COMMENT '数据来源描述', total_rows INT COMMENT '本次更新的记录条数', status TINYINT COMMENT '1成功 0失败', fail_reason VARCHAR(255), create_time DATETIME );

日志表同样重要，它意味着你的系统被设计成“可追踪”的，每次定时任务执行结果都有据可查。写论文时，这一张表能撑起“系统可靠性设计”小节的半页内容，答辩时还可以直接翻日志表证明系统真的在自动更新数据。

4. 后端接口设计与定时任务：把“实时”落地

4.1 对外提供哪些REST接口

APP端所有页面都围绕下面的接口来工作。接口设计我遵循最朴素的REST风格，URL即资源，动词交给HTTP method：

请求方式	接口路径	功能说明
GET	/api/country/list	获取全球所有国家最新统计数据
GET	/api/country/{code}	获取单个国家的最新统计
GET	/api/country/{code}/trend?days=30	获取某国近30天趋势数据
GET	/api/rank?sort=confirmed&limit=20	获取确诊数排名前20的国家
GET	/api/continent/{name}	按大洲聚合查询
POST	/api/admin/import	管理后台手动导入数据（仅管理员）

这个接口设计里最有讲究的是“趋势”接口的days参数。为什么不直接写死返回30天？因为论文里要体现你对可扩展性的考虑。days参数化之后，APP可以支持用户切换近7天、30天、90天的趋势图，评分点直接+1。另外，所有列表类接口默认只返回“每个国家最新一条”，这个逻辑必须在SQL里用GROUP BY country_code配合MAX(update_time)来实现，而不是在Java里循环筛选，否则接口会慢到让你怀疑人生。

4.2 定时任务的核心代码实现

“实时”的核心引擎是Spring的定时任务。以下代码展示每日更新的完整逻辑：

@Component public class DataSyncTask { @Autowired private CountryStatsService statsService; // 每天凌晨 2:30 执行，避开高峰 @Scheduled(cron = "0 30 2 * * *") public void syncDailyData() { // 记录本次更新的元信息 DataUpdateLog log = new DataUpdateLog(); log.setUpdateSource("公开数据聚合"); log.setStatus(1); try { // 1. 从数据源拉取原始数据（JSON格式） String rawJson = HttpUtil.get("https://your-data-source.example.com/global"); // 2. 解析成结构体列表 List<CountryDailyStats> list = parseJsonToStatsList(rawJson); // 3. 去重后批量入库：同国家+同日期则更新，否则插入 int affected = statsService.batchUpsert(list); log.setTotalRows(affected); } catch (Exception e) { log.setStatus(0); log.setFailReason(e.getMessage()); } // 4. 写日志 statsService.saveLog(log); } }

这里最关键的是batchUpsert方法，它解决了“重复数据如何处理”的问题。我的做法是使用ON DUPLICATE KEY UPDATE语法，前提是给表建立country_code + update_time的唯一索引，那么每次同步时，如果同一个国家同一天的数据已经存在，就更新数值，不会产生脏数据。如果不同时间点的两条数据应不同，那么把时间精确到小时的维度即可。这个细节在论文数据结构设计中一定要写清楚，属于“你踩过坑后才知道的细节”。

4.3 数据源的取舍与离线兜底方案

关于数据从哪来，这几乎是每个学生都会卡住的坑。市面上的免费实时疫情API接口，很多现在已经关闭或者不再更新了，直接依赖外部接口会让你在使用演示前突然拿不到数据。我的建议是采用**“一次导入 + 定期脚本更替”**的兜底策略：

• 项目初始化时，准备一个CSV文件，包含主要国家/地区近一年每日数据，用导入接口批量入库，保证系统演示时一定有效
• 定期从公开渠道获取增量数据，通过管理后台的手动导入功能更新
• 数据源来不及更新时，定时任务会失败，但系统不会崩溃，因为日志表记录了失败原因，且APP端还有历史数据可以展示

这道兜底逻辑还要在论文“系统测试”章节写一段“异常数据源容错处理”，堪称整个系统的防弹衣。总之外部数据源的稳定性不在你控制范围内，系统自身的完整性才是你可控的部分。

5. APP端核心实现：图表、列表与请求封装的实战细节

5.1 项目结构与依赖配置

APP端我按“基础封装 — 业务页面 — 图表组件”三层来组织代码。先看build.gradle的关键依赖：

dependencies { implementation 'androidx.appcompat:appcompat:1.6.1' // HTTP 网络请求框架 implementation 'com.squareup.retrofit2:retrofit:2.9.0' implementation 'com.squareup.retrofit2:converter-gson:2.9.0' // 图表绘制 implementation 'com.github.PhilJay:MPAndroidChart:v3.1.0' }

为什么要用Retrofit而不是原生的HttpURLConnection？因为Retrofit+RxJava能自动完成JSON到JavaBean的转换，代码量减少80%，而且它的请求日志拦截功能在调试阶段帮了我大忙。下面这段是接口定义与单例封装的写法：

public interface ApiService { @GET("api/country/list") Call<List<CountryStats>> getCountryList(); @GET("api/country/{code}/trend") Call<List<TrendPoint>> getCountryTrend(@Path("code") String code, @Query("days") int days); }

public class RetrofitClient { private static final String BASE_URL = "http://10.0.2.2:8080/"; // 注意：10.0.2.2 是 Android 模拟器访问本机的固定地址 // 真机调试时改为电脑的局域网IP，如 http://192.168.1.102:8080/ private static ApiService apiService; public static ApiService getApiService() { if (apiService == null) { Retrofit retrofit = new Retrofit.Builder() .baseUrl(BASE_URL) .addConverterFactory(GsonConverterFactory.create()) .build(); apiService = retrofit.create(ApiService.class); } return apiService; } }

这个BASE_URL的设置是我见过最多学生栽跟头的地方。模拟器里用的是10.0.2.2，不是localhost；真机调试时必须用电脑的局域网IP，并且要确保手机和电脑连的是同一个WiFi。如果后端Tomcat没在公网部署，这个地址配置错了，其他代码再完美页面也是白的。强烈建议把BASE_URL做成一个可在设置页修改的配置项，论文里还能写“系统支持多环境部署”。

5.2 列表页与排名页的适配器写法

全球国家列表页是APP的门面。我的做法是使用RecyclerView，通过CountryListAdapter来渲染国家名、结肠数据值和更新时间。在实现了排名接口后，列表页还可以加一个“按确诊数降序排列”的开关，APP端只传排序参数给后端，不自己排序。这个细节很微妙但也特别容易加分：你向评委强调“排序逻辑放在数据端，不做全量数据的内存排序”，是性能优化的正确意识。

5.3 趋势曲线的核心实现

趋势图是答辩时视觉效果最好的部分。MPAndroidChart绘制折线图的代码并不复杂，难点在于把后端返回的时间字符串数组转换成图表坐标点：

LineDataSet dataSet = new LineDataSet(entries, "确诊趋势"); dataSet.setColor(Color.parseColor("#E53935")); dataSet.setCircleColor(Color.parseColor("#E53935")); dataSet.setLineWidth(2f); List<ILineDataSet> dataSets = new ArrayList<>(); dataSets.add(dataSet); LineData lineData = new LineData(dataSets); chart.setData(lineData); chart.invalidate();

这里有个细节：当数据量大时，X轴标签会挤成一团。我踩过的坑是默认让MPAndroidChart自己去处理X轴密度，结果30天的数据全叠在一起。正确做法是设定X轴的最小间隔，或者每5天显示一个刻度。代码里加一句xAxis.setGranularity(5f)就能解决问题。这个细节在演示现场如果被评委注意到，他会觉得你确实调过实战项目，而不是只会拷贝别人的demo。

5.4 大屏适配与页面缓存

APP端的列表页和图表页还需要考虑不同分辨率的适配。我建议布局文件全部使用ConstraintLayout配合dp单位，不要用px写死。数据加载时用SwipeRefreshLayout实现下拉刷新，同时加载完成前显示ProgressBar，加载失败时显示一个友好的重试按钮，后台日志里记录的是接口排错信息而不是抛一堆闪退日志。这套交互虽然简单，但体现了你对用户体验的基础认知，答辩时能多聊两分钟。

6. 论文撰写与答辩准备：好项目也要讲得好

6.1 论文结构怎么定

写论文最忌讳上来就写需求分析，写了一堆正确的废话。我给学生的建议是采用“逆向写作法”：先把系统页面的截图和核心代码跑通，再回头写前面的章节。论文结构可以参考：

章	标题	核心内容与篇幅建议
第1章	绪论	研究背景与意义、国内外现状、主要工作，约4页
第2章	相关技术介绍	SSM三大框架、Android技术栈、MPAndroidChart、JSON，约5页
第3章	系统需求分析	功能需求（APP端/后台端）、非功能需求（安全性/性能）、用例图，约8页
第4章	系统设计	总体架构、各模块功能设计、数据库表设计、时序图，约10页
第5章	系统实现	后端定时任务、接口实现、APP端各页面实现，配核心截图+代码，约12页
第6章	系统测试	功能测试用例表、性能测试结果、异常测试，约6页
第7章	总结与展望	个人收获、不足、改进方向，约2页

这套结构总共约47页，加上封面、目录、参考文献，刚好在55页左右，非常标准。写第5章时注意一个原则：核心代码要贴，但不能贴整整页。每个功能模块贴5-8行关键代码即可，比如定时任务的注解、MyBatis的批量更新SQL、Retrofit的接口定义。代码周围必须配一段说明文字解释“为什么这么写”，这才叫毕业设计论文，而不是代码粘贴文档。

6.2 答辩时评委最常问的10个问题

提前准备答辩问答题库，比背PPT有效得多。以下问题我整理了多年来的高频问题，每个都附带推荐回答思路：

• 为什么用SSM不用Spring Boot？答：毕业论文选题要求体现传统Java Web开发的完整流程，SSM在配置层面要求开发者手写Spring配置、Spring MVC配置和MyBatis映射，更有助于理解底层原理；同时SSM也是教学体系中教授的技术栈。
• 数据每天更新一次，算“实时”吗？答：本系统的实时定位为“近实时”，通过定时任务每24小时自动同步保证数据新鲜度，对疫情统计场景，粒度为一天的实时已满足需求；如需更强实时性，可在架构中引入消息队列。
• 解决过哪些数据重复问题？答：通过唯一索引和ON DUPLICATE KEY UPDATE实现UPSERT，同一国家同一统计日期只保留最新值。
• 外部数据接口挂掉怎么办？答：系统设计采用“离线兜底”策略，保留历史数据可查询，定时任务失败会记录日志并触发管理端告警，不影响APP主体功能。
• APP如何保证在不同手机上适配？答：布局采用ConstraintLayout+dp单位，图表库基于原生绘制自适配分辨率，同时在测试阶段覆盖了主流模拟器分辨率。
• 业务中的事务怎么控制？答：批量导入数据使用了@Transactional注解，一旦中间某条数据入库失败，整批事务回滚，避免半更新状态。
• 有没有做权限控制？答：后台上传/删除接口使用拦截器校验Token管理员身份，APP端接口全部设为只读，不同权限角色做了菜单级别隔离。
• 前后端交互的怎么做安全处理的？答：主要做了SQL注入防范（MyBatis参数化查询）、接口返回字段过滤、APP请求的Token鉴权，论文的非功能需求分析中有详细说明。
• 如果并发量上百，怎么优化？答：目前系统瓶颈在数据库查询，可引入Redis做缓存层，把国家列表这类高频只读接口缓存到Redis，淘汰策略使用LRU，能显著提升吞吐量。
• 你做这个项目最大的难点是什么？答：很难说，但要准备好一个真实的故事。最好讲数据同步的幂等性和APP图表渲染的性能优化，这两个是真正踩到坑的点，讲出了细节才算真做了。

6.3 演示视频录制的三个细节

演示现场出状况的概率不低，特别是网络问题。我的建议是提前录制一个5分钟左右的演示视频作为planB，录制时注意三点：打开后端的日志窗口，让审计日志和更新日志在屏幕上滚动；操作顺序从“首页列表 - 国家详情图 - 排名页 - 后台数据管理”逐步走；模拟一次“数据接口断网”场景，展示系统的容错提示界面，这反而是加分点。

7. 常见问题与工时规划速查

7.1 高频报错与排查手册

症状	可能原因	排查与解决
Tomcat启动报404，但控制台无异常	Spring MVC扫描包路径配置错误	检查<context:component-scan>的base-package是否覆盖Controller所在包
APP请求接口返回Connection refused	BASE_URL地址错误，或后端未启动	先用浏览器访问BASE_URL + 接口路径测试，确认后端可访问
列表页数据为null但接口200	Gson解析字段名与Java属性名不一致	如果字段是country_name，Java属性应为countryName，开启Gson的setFieldNamingPolicy的SNAKE_CASE
定时任务不执行	漏加@EnableScheduling注解	SpringBoot项目在启动类加@EnableScheduling，SSM纯XML项目需在Spring配置中加<task:annotation-driven/>
图表X轴文字重叠	未设置最小刻度间隔	设置xAxis.setGranularity(5f)或调整setLabelCount
MySQL中文乱码	连接字符串未指定编码	JDBC URL加useUnicode=true&characterEncoding=utf8，建表时确保DEFAULT CHARSET=utf8mb4
MyBatis报“Invalid bound statement”	Mapper接口与XML文件namespace不一致	核对namespace是否为接口全限定名，resultType是否为实体类全限定名
APP在真机上跑，列表页闪退	手机未授予网络权限	在AndroidManifest.xml中加<uses-permission android:name="android.permission.INTERNET"/>

7.2 时间规划：八周稳妥完工

很多学生不是能力不够，而是进度管理失控。给一个按正常上课节奏规划的时间表：

周次	任务	产出物
第1周	选题确认、需求分析、技术调研	开题报告初稿
第2周	数据库设计、表结构定稿、SSM框架环境搭建	数据库设计说明书、可启动的空项目
第3-4周	后端代码：实体类、Mapper、Service、Controller、定时任务	可调试的后端服务，接口自测通过
第5周	数据导入与仪表盘验证，准备演示数据	后端接口支撑真实数据的可用版本
第6周	APP端：列表页、详情页、图表、网络层封装	可安装运行的APK
第7周	系统测试、Bug修复、演示视频录制	测试报告、演示视频
第8周	论文撰写与格式调整	送审论文

这套计划的好处是每个阶段都有明确的可检查产出物，不会出现“前六周都在纠结，最后两周熬夜爆肝”的悲剧。特别提醒一句话：第5周前必须保证后端能跑通，因为后面所有APP开发都要依赖接口调试，你把数据接口拖到最后，等于给你的手机端开发埋了一颗定时炸弹。

最后说点掏心窝的话

带毕设这几年，我见过太多学生把精力花在“找现成源码”和“改个皮”上，结果答辩时被评委问到哪个类的完整结构都答不上来。其实SSM这个技术栈真的不难，难的是静下心把一条完整的链路走一遍。疫情统计系统这个题目，数据规模适中，逻辑清晰，前端展示效果又足够亮眼，属于性价比非常高的一类毕业设计。你要是能按这篇文章的思路，把“定时任务 + 宽表设计 + 接口分层 + APP图表”这四个核心模块真正吃透，不仅论文不会愁，面试时聊到Java后端，你也能拿出来当真实项目经验来谈。最后再分享一个小技巧：所有拦截器返回的JSON格式，统一用{code:200, message:"success", data:...}这套结构，前后端联调时真的能省一半时间，因为我就是这么一路踩过来的。希望这篇经验贴能帮你在毕设这条路上少掉几个坑，祝顺利。