SpringBoot全国降水数据分析与可视化系统实战：从数据清洗到ECharts联动

上个月有个同学拿了个毕业设计题目来问，题目大概是"基于SpringBoot的全国降水数据分析与展示可视化系统"。他当时第一反应是：这不就是一个地图页面，后端查数据返回，前端把点和颜色画出来就行了吗？等我让他把需求拆开——"分析"这两个字往细了说，他才意识到，从数据清洗、指标计算到前端联动展示，工作量比他预想的大了一个量级。

这篇内容就是围绕这个题目展开的，我把它当作一个完整的毕设技术复盘来写。核心涉及SpringBoot后端架构、全国降水数据的获取与清洗、分析指标的后端聚合实现、ECharts地图与联动图表的实现，以及部署和说明文档（很多题目描述里会写LW，指的就是论文和配套文字材料）的经验。适合正在做同类"数据分析+可视化"方向毕业设计的人参考，也适合想从零搭一套前后端分离数据展示项目的读者。

1. 拿到这个毕设题目后，真正要解决的三个问题

1.1 降水数据"分析"和"展示"分别指什么

先说一个很多人理解偏差的地方。"全国降水数据分析与展示"不是一个查出来再画图的事，它拆开来看至少包含三个层次：

• 时间维度：全国每年的平均降水量是多少？某省近十年的降水量是上升还是下降？哪个月是降水高峰？这些要落到"按年份分组求平均值""按月分组求累计值"这类聚合逻辑上。
• 空间维度：不同省份之间降水量差异有多大？年内降水集中在哪几个区域？能不能按省级行政区做排名和地图着色？
• 指标维度：除了平均值，还要不要算极值、方差、降水集中度？会不会涉及"某日降水量超过阈值"的极端降水统计？

"展示"也不只是画图。展示包含地图下钻、时间轴筛选、图表类型切换、前后端数据联动。做得好一点，用户选一个年份，全国地图颜色变化、排名榜刷新、右侧趋势图重绘，这是一套完整的交互逻辑。

1.2 "设计"和"实现"这两个词，对应答辩老师考察的能力

毕业设计题目里最容易被低估的是"设计与实现"这五个字。它不是一个页面的事，它对应的是：

• 需求分析：题目里每一个功能点对应什么用户场景；
• 架构设计：前后端方案、数据库表结构、数据流向；
• 数据库设计：表字段、索引、数据规模；
• 核心代码实现：聚合统计、接口设计、图表数据组织；
• 系统测试与部署：数据库初始化、项目打包、演示环境。

很多同学把时间全花在写前端页面，结果到了写论文的时候发现没有东西可写。实际上，毕设的评分重点不只是"跑得起来"，更重要的是"你的设计思路清不清楚、工作量是否饱满、是否体现了完整的软件工程流程"。

1.3 这篇博文怎么帮你把这套东西做出来

我按做这个项目的完整流程来讲：先是技术选型和数据建模，然后是数据获取与清洗（这块是最耗时的），再到后端接口和聚合统计的实现，然后是可视化联调，最后是部署和文档。每一段我都会结合自己做类似项目时遇到的问题，比如数据缺失怎么处理、地图下钻用什么格式、跨域和时区在哪里翻车等。

特别提醒一句：本文说的不是某个现成源码的运行教程，而是把"如果你要从头把这个系统实现出来，每一步应该怎么设计和落地"讲清楚。你拿着这套思路去对比任何一套类似源码，都能一眼看出它好在哪里、缺在哪里。

2. 技术选型与数据建模：为什么SpringBoot是这个题目的最优解

2.1 SpringBoot到底解决了毕设开发里的什么痛点

先说结论：这个题目用SpringBoot作为后端框架，是很合理的选择，但不是因为它"能做数据分析"，而是因为它能让你把时间花在业务逻辑而非环境配置上。

很多学校的Java课程还在讲SSH或SSM，XML配置写一大堆。SpringBoot最核心的价值是自动配置和起步依赖。举个例子，你要整合Spring MVC和MyBatis，传统SSM要写web.xml、spring-mvc.xml、mybatis-config.xml，还要处理各类Bean扫描配置。SpringBoot里只要引入依赖，然后在application.yml写数据源信息就行。内嵌Tomcat也让部署变简单，IDEA里直接跑main方法就能启动。

但你要知道，SpringBoot本身不做数据分析，它更多是承担"接口服务"的角色。

选这套组合的优势在于：每个环节都有大量现成资料，遇到问题能在搜索引擎上快速找到方案。对毕设来说，"不容易卡住"就是最大的效率优势。

2.2 全国降水数据模型怎么设计才不会返工

数据建模是最容易返工的地方，我见过有人把表设计成全字段大宽表，结果后面写聚合SQL时发现索引没法建，查询慢到离谱。

这个项目的核心表一般就是一张"降水记录表"，字段可以这样设计：

为什么推荐把province和city直接作为字段存进去，而不是单独建一个区域维表再做关联？因为毕设系统的数据量级别通常不会大到需要三范式来节省存储，数据模型第一要务是"好理解、好查询"。你写聚合SQL的时候，按province和record_date直接GROUP BY，比join维表方便得多。这属于实际项目里常见的"反范式设计"，也是答辩时可以讲的一个点。

需要说明的是，不要一上来就设计一张包含所有可能字段的宽表，比如经纬度、海拔、风速、湿度等一股脑都加上。字段越多，清洗压力越大，后面写文档越难讲清楚。先把核心的降水记录做好，其他字段作为可扩展项在论文里提一句就够了。

2.3 数据库选型和索引设计

数据库用MySQL InnoDB引擎就够了，重点是把索引设计对。

降水查询最典型的是按时间和区域过滤，所以联合索引就这样建：

ALTER TABLE precipitation_data ADD INDEX idx_province_date (province, record_date);

这个索引支撑"某省某年降水量"、"某年各省降水量排名"这类高频查询。查询条件里涉及日期的范围过滤，会走索引的前缀匹配，效率高很多。

如果数据量达到几百万行以上，还可以考虑按年份做分区表或分表，但这对毕设来说一般不是必须的。在论文里把"为什么设计这个索引"写清楚，比真的去优化千万级数据更有价值。

数据来源如果是公开气象数据集，导入脚本建议做分批插入，避免一次性插入几十万条SQL把连接卡死。

3. 数据获取与清洗：不把数据搞定，后面全是白搭

3.1 降水数据从哪来：真实数据与模拟数据的取舍

做这个项目的同学最先问的问题就是：数据在哪下载？

常规做法有两个方向，你可以根据自己的情况取舍。

第一，使用公开的历史气象观测数据。这类数据通常是以站点为单位的日值数据集，涵盖全国多个气象站点的降水量、气温等要素。拿到后需要做坐标到省市的匹配，再把站点数据按省汇总。优点是真实、有说服力；缺点是数据文件格式杂乱，年份跨度大，清洗工作量大。

第二，生成模拟数据。如果你拿不到完整的数据集，或者时间来不及清洗，可以用脚本按"某省某市某日降水量"的方式生成模拟数据。关键是让模拟数据符合真实的降水分布特征：整体而言，南方较多、北方较少；夏季降水多、冬季降水少；某些区域日降水会远大于均值。用正态分布加季节性偏移来生成，展示效果是合理的。

我在实际带项目时会让学生优先尝试真实数据，因为真实数据自带缺失值、异常值，处理流程能写进论文。如果数据实在拿不全，再退一步用模拟数据，但要在论文里明确说明数据来源属于"演示数据"。

3.2 缺失值、异常值和重复数据的处理策略

降水数据最常见的问题是缺失——某一天、某个站点没有观测值。处理方式有三种：

• 直接删除：缺失比例小的时候可以删；
• 标记为NULL：在统计时排除，展示时注明"数据缺失"；
• 插值填充：用前后天数值取平均填入，适合连续缺失不超过两三天的场景。

异常值更值得注意。比如降水量的负值，这明显是数据异常，应直接清洗掉；比如某站某日降水量是几百毫米，单个站点确实可能出现特大暴雨，但在没有官方确认的情况下，建议设置一个合理的阈值范围，超过则标记为异常再人工确认。

清洗脚本用Java或Python写都行，我习惯用Python处理原始文件，处理完导出CSV，再写一个Java的批量导入逻辑入库。整个流程在论文里是很好的一个章节"数据预处理"，这一点特别加分，因为很多毕设根本不写数据清洗。

3.3 数据入库与测试环境的数据规模设计

数据入库建议走脚本，而不是手写SQL插入。脚本有两种写法：

一种是用SpringBoot写一个DataImportRunner，在项目启动时读取CSV并逐批插入数据库：

@Component public class DataImportRunner implements CommandLineRunner { @Autowired private PrecipitationMapper mapper; @Override public void run(String... args) { // 读取csv并调用 mapper.batchInsert(list) } }

另一种是直接用Python脚本连接MySQL执行批量插入：

# pip install pymysql import pymysql conn = pymysql.connect(host="localhost", user="root", password="123456", database="rain_db") cursor = conn.cursor() sql = """insert into precipitation_data(province, city, record_date, precipitation) values(%s, %s, %s, %s)""" data = [] for row in csv_reader: # 模板需要补充：每行读取 as province, city, date, precipitation data.append((province, city, date, precipitation)) cursor.executemany(sql, data) conn.commit()

关于数据规模，建议至少覆盖近十年以上、全国各省的日值或月值数据。这样时间轴筛选有得选，地图排名也有明显差异。数据太少的话，图表一拉出来就露馅了，答辩时被问"你这个趋势分析能说明什么"会很难回答。

4. 核心分析接口的设计思路：聚合统计放SQL还是放代码

4.1 时间维度的统计分析

后端接口是整套系统的核心。分析接口的通用设计模式是：前端传过来年份、省份、指标类型，后端根据参数生成聚合SQL，查询后返回结构化JSON。

先说时间维度的分析。比如"某年各省年平均降水量"：

// 接口：/api/analysis/yearly // 参数：year // 返回：List<Map<String, Object>>

对应的SQL是：

SELECT province, ROUND(AVG(precipitation), 2) AS avg_precip FROM precipitation_data WHERE YEAR(record_date) = #{year} GROUP BY province ORDER BY avg_precip DESC;

注意一点：如果数据粒度是日值，YEAR(record_date)这个写法在数据量小的时候OK，但在数据量大时会导致索引失效。可以在查询前先用日期范围缩小数据，或者直接在表里冗余字段存储年份，再对year字段建索引。毕设规模下用YEAR()函数没有问题，但你能在论文里写一句"考虑到索引优化，可增加年份冗余字段"，会显得思考得比较细。

季度分析则是把月份映射到季节：3-5月为春、6-8月为夏、9-11月为秋、12-2月为冬。SQL可以写成：

SELECT province, CASE WHEN MONTH(record_date) BETWEEN 3 AND 5 THEN '春' WHEN MONTH(record_date) BETWEEN 6 AND 8 THEN '夏' WHEN MONTH(record_date) BETWEEN 9 AND 11 THEN '秋' ELSE '冬' END AS season, ROUND(AVG(precipitation), 2) AS avg_precip FROM precipitation_data WHERE YEAR(record_date) = #{year} GROUP BY province, season;

4.2 空间维度的区域对比

空间维度的核心接口是"各省降水排名"和"各省降水对比"。

排名接口：

SELECT province, SUM(precipitation) AS total_precip FROM precipitation_data WHERE YEAR(record_date) = #{year} GROUP BY province ORDER BY total_precip DESC;

如果你希望展示的是"年降水量总量"，用SUM；如果展示"平均降水量"，用AVG。两者含义不同，前端图表的标题也要写清楚。

区域对比则可以把全国分为若干区域来做汇总，比如按地理方位划分几大片，分组求平均值后返回。这个指标适合在论文里写"区域降水差异分析"，答辩时很好讲，因为你能从数据结果明显看出差异。

4.3 极端降水与趋势指标怎么实现

如果只做平均和总和，项目深度是不够的。我建议在系统里加两个更"有思考"的指标：极端降水事件统计和降水趋势变化。

极端降水事件可以定义：日降水量大于等于50毫米视为暴雨日，统计各省指定年份的暴雨日数量。

SELECT province, COUNT(*) AS heavy_rain_days FROM precipitation_data WHERE YEAR(record_date) = #{year} AND precipitation >= 50 GROUP BY province ORDER BY heavy_rain_days DESC;

趋势变化可以用"逐年全国平均降水量"来体现，接口返回连续多年的平均值，前端画成折线图，再叠加一个移动平均曲线。移动平均在代码里算就行：

// 计算三年滑动平均 for (int i = 1; i < values.length - 1; i++) { avg[i] = (values[i-1] + values[i] + values[i+1]) / 3.0; }

这种指标的价值在于：它不是直接从数据库查出来的"流水账"，而是经过业务处理和计算的"分析结果"。答辩时老师问"你分析出了什么"，你能用趋势图的走向、暴雨日的省份分布给出有数据支撑的回答，这比"我做了个展示页面"强很多。

5. 可视化展示层的实现：从地图到多维联动

5.1 全国地图怎么做：ECharts地图注册与数据格式

可视化部分是同学最喜欢先动手的部分，这里最容易踩的坑反而是第一行数据。

ECharts做全国地图需要GeoJSON格式的地图数据。近几年的ECharts版本里，地图数据需要通过registerMap注册：

import * as echarts from 'echarts'; import chinaJson from './china.json'; echarts.registerMap('china', chinaJson); let chart = echarts.init(document.getElementById('map')); chart.setOption({ series: [{ type: 'map', map: 'china', roam: true, label: { show: true }, data: [ { name: '某省', value: 1200 }, { name: '某省', value: 800 } ] }] });

地图数据的name值必须与GeoJSON里每个省级区域的name属性完全一致，否则会渲染不出来。实际开发中常见的问题是"地图上某个省份空白"，十有八九是数据里的省名和地图文件里的省名不匹配，比如"内蒙古"和"内蒙古自治区"的写法差异。

如果要做市级下钻，你需要的是市级GeoJSON。数据规模会从几十条变成几百条，而且后端要按市级维度聚合。对毕设来说，做到省级粒度已经足够完整，下钻可以作为扩展功能写进论文"系统扩展性"部分，不必真的实现。

5.2 时间轴筛选与联动方案

不少同学的第一版联调是：前端选年份，发起一次Ajax请求，重新加载图表数据。这个逻辑没有错，但性能差。特别是全国地图和多个图表同时要数据时，一次年份切换就会触发四五次请求。

更好的做法是页面初始化时一次性拉取全部年份的聚合数据，前端根据选中年份在内存中取数并重绘图表。举个例子，初始化请求/api/analysis/allYearly，返回结构：

{ "years": [2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024], "yearlyAvg": { "2015": 640.2, "2016": 658.1 }, "provinceByYear": { "2015": [{"province": "某省", "value": 1500}, ...] } }

前端切换年份时，只需要从provinceByYear里取对应年份的数据，调用chart.setOption更新。这样本地操作几乎零延迟，演示流程丝滑，也不会被网络请求拖累。

这套设计在文档里是很好的一个点，因为它体现了"前端性能优化"意识，虽然是简单优化，但面试或答辩时一提"减少接口调用次数"，老师基本都能给正向反馈。

5.3 前端布局和图表组织

推荐一个经典布局：页面顶部放时间轴和指标切换器，中间主体是全国地图，左侧是降水排名TOP10柱状图，下方是历年趋势折线图。整个页面一个纵向信息流，填完整个屏幕，演示起来很完整。

ECharts组件之间的联动除了数据联动，还可以做"点击省份联动"。比如用户点击地图中的某省，右侧折线图切换为该省历年降水量变化。这个交互用ECharts的click事件实现：

chart.on('click', function (params) { let provinceName = params.name; // 根据省份更新右侧图表数据 updateLineChart(provinceName); });

这个功能不会增加太多工作量，但对系统的交互完成度提升非常明显。答辩演示时老师点一下地图，图表跟着变，视觉效果和工程感都比静态页面好太多。

6. 前后端联调与部署：毕设答辩前最容易翻车的地方

6.1 跨域、中文乱码和时区：必踩三连

跨域问题只在前后端分离部署时出现。SpringBoot后端处理方式很简单，写一个配置类：

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

中文乱码一般出现在两个地方。一是数据库连接URL没有指定UTF-8：

spring: datasource: url: jdbc:mysql://localhost:3306/rain_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

二是返回JSON时中文乱码，SpringBoot 2.x以上一般默认是UTF-8，但如果发现乱码，检查一下是否手动改过HttpMessageConverter，或者前端页面meta标签有没有声明charset=utf-8。

时区问题典型表现是：前端传一个"2024-01-01"，后端用Date接收后却变成"2023-12-31"。所以数据库连接参数里serverTimezone=Asia/Shanghai一定要写，Java时间类型建议直接用LocalDate而不是Date，避免时区带来的偏移。

6.2 Maven打包、部署与演示环境

后端部署一个就够了，本地演示场景下直接在IDEA里启动。如果你需要在服务器上跑，用Maven打jar包：

mvn clean package -DskipTests java -jar target/rain-analysis.jar

前端如果是静态页面，可以放在dist目录里，用Nginx做静态代理，再把API请求反向代理到后端服务。配置模板：

server { listen 80; location / { root /home/project/dist; index index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; } }

演示前一定准备一套"兜底"方案。我见过不止一次现场演示时数据库连不上，或者图表数据加载失败。建议演示前重启一次服务，确认数据库脚本可以重复执行，页面刷新不会只出现白屏。把数据库初始化脚本、启动步骤说明一起放进说明文档里，这是"调试定制"和"说明文档"这两个描述落到实处的核心体现。

6.3 数据库脚本和说明文档的完整清单

一份合格的说明文档（LW配套材料）通常要包含这几部分：

• 项目概述和功能说明；
• 开发环境清单：JDK版本、Maven版本、MySQL版本、Node版本；
• 数据库初始化：建库SQL脚本、初始数据文件、导入步骤；
• 后端启动步骤：修改application.yml数据源配置，运行main方法；
• 前端启动步骤：npm install / npm run dev，或静态页面直接打开；
• 系统演示流程：核心功能对应哪些页面路径；
• 常见问题：端口被占用、数据库驱动版本冲突、跨域配置。

这一步看起来简单，但很多项目失败在"别人拿到项目后跑不起来"。文档的意义就是让你的毕设成果真正可复现。

7. 论文与答辩环节的个人经验

7.1 每个章节怎么写得又快又扎实

论文写作顺序建议和开发顺序一致，不要先写摘要。具体顺序：先画架构图，再写需求分析，然后写数据库设计，再写核心代码实现，最后补测试。

需求分析要做的第一步是"用例分析"。把系统功能拆成序列：普通用户浏览全国降水地图、选择年份查看降水分布、点击省份查看趋势、系统管理员维护数据。一条用例对应一个功能模块，论文结构自然就出来了。

数据库设计章节要放ER图，然后逐表说明字段含义。核心表就是降水记录表，加上用户表（如果有登录功能）、统计结果缓存表（如果有）。每张表写清楚主键、索引、字段注释。

核心代码实现不要贴大段源码。最佳方式是一段核心代码加一段解释。比如你贴聚合统计的Mapper接口，配上"这里使用GROUP BY和聚合函数，将日值数据压缩为按省、按年统计结果"就够了。论文不是代码仓库，它考察的是你的理解和表述。

7.2 答辩时怎么把这些工作量讲满

答辩时间通常五分钟讲PPT，十分钟提问。我建议按这条主线讲：选题背景 → 技术选型 → 数据获取与清洗 → 系统设计 → 核心功能演示 → 总结与展望。

老师大概率追问的点集中在这几类：

• 为什么选SpringBoot？因为它的自动配置和起步依赖降低了开发难度，生态完善，适合快速搭建数据展示类系统。
• 数据处理过程遇到了什么问题？回答真实数据的缺失值、异常值处理，以及批量入库时的性能问题，这是你工作量最直观的体现。
• 聚合统计的SQL原理是什么？讲GROUP BY的执行思路，以及索引如何优化查询。
• 系统有哪些可扩展的地方？市级地图下钻、实时数据接入、预测算法，只要你想到，就说明你思考过系统的边界。

回答问题的核心原则是"讲过程、讲取舍"。开发中踩过坑、改过方案、做过对比，都比"我直接用了某框架"有说服力。

我个人的体会是，这类题目真正拉开差距的不是谁地图画得好看，而是谁把"数据"到"信息"再到"结论"的链条讲完整了。降水原始数据只是数字，清洗和聚合后是统计指标，放到地图和图表里才变成能被理解的信息。你的论文和答辩，讲清楚的就是这条链。后面如果时间充裕，可以往两个方向扩展：一是接更细粒度的市级数据做下钻，二是把移动平均换成更复杂的趋势拟合算法。但先把现有的省级版本做到稳定、美观、文档完整，这个题目的核心分就拿到了。