目录
五、系统架构：Flask、MySQL、Pyecharts与ECharts协同工作
有需要本项目的代码、文档、完整资源，或者需要部署调试的朋友，可以私信博主。
做气候环境数据分析时，我最先遇到的问题不是图表怎么画，而是数据怎么稳定地拿到、怎么整理成统一口径、怎么让用户一眼看懂。广西各市的天气、温度、风向、空气质量等指标本身并不陌生，但它们散落在不同页面、不同月份和不同字段里，如果只停留在表格层面，很难看出长期趋势、城市差异和季节变化。基于这个想法，我把项目定位成一个完整的数据分析与可视化平台：前端能看图、后台能管数、模型能预测、大屏能展示。
系统围绕广西14个地级市的历史气候环境数据展开，覆盖2020年至2025年前后的气温、天气、风向、风力、AQI、空气质量等级等指标。项目技术栈以Python为核心，使用Flask搭建Web服务，MySQL负责结构化存储，Pandas完成清洗和统计，Pyecharts用于批量生成单页图表，ECharts用于动态大屏渲染，LSTM和GRU用于AQI短期趋势预测。整个过程从数据采集开始，一直延伸到用户登录、权限管理、数据维护、指标分析和可视化大屏展示，形成了一个可运行、可展示、可扩展的闭环系统。
一、项目缘起：把分散的天气记录做成可分析的数据资产
广西地形复杂，沿海、丘陵、盆地和山区并存，气候表现也有明显的空间差异。南部沿海受海洋调节影响更强，桂北山区的温差和冷空气影响更明显，西部部分城市在夏季高温上表现突出。单独看某一天的天气预报，只能知道"今天热不热、有没有雨"；把多年数据放在一起，才能看到更有价值的问题：哪些城市长期空气质量更稳定，哪个月份AQI容易升高，风向和空气质量之间有没有关联，极端高温主要集中在哪里。
这个系统要解决的正是从"天气记录"到"环境洞察"的转换。项目中我没有只做几张静态图，而是把数据链路、Web系统和预测模块放到同一个框架里。普通用户可以查看不同主题的可视化页面，管理员可以维护用户和气象数据，后台可以查看数据增长与用户访问情况，大屏页面可以把关键指标整合到同一屏幕上，适合课程展示、毕业设计答辩、项目演示或后续二次开发。
图 1 数据采集、清洗与预测建模流程
二、数据采集：从网页历史天气到本地结构化数据
项目的数据主要来自公开历史天气页面。采集时按城市和月份组织请求，逐步抓取广西各市的逐日历史记录。原始页面中包含日期、最高气温、最低气温、天气状况、风向、风力、AQI、空气质量等级等字段，这些字段看起来简单，但在工程处理时需要考虑很多细节。例如不同年份的页面路径并不完全一致，部分月份存在缺失字段，部分AQI信息需要根据月度汇总值进行补充，温度字段还带有单位符号，不能直接用于计算。
为了让采集过程尽量稳定，我在爬虫端做了请求头伪装、随机延时、失败重试和批量城市遍历。每次请求之间保留间隔，避免高频访问造成失败；当某个月份请求异常时，程序会等待后再次尝试，并记录日志方便回查。最终整理出的原始记录超过三万条，覆盖广西主要城市的多个气候维度，为后续清洗、建模和可视化提供了基础。
图 2 历史天气数据采集与原始记录展示
三、数据清洗：让气象字段变得统一、可统计、可建模
爬取下来的原始数据并不能直接进入可视化页面。项目里我把清洗过程分成字段解析、格式转换、缺失值处理、异常值检查、特征派生和数据库入库几个步骤。日期字段统一转成标准时间格式，气温字段去掉"℃"后转为数值，天气描述按关键词拆分出主要天气类型，AQI字段则补齐缺失记录，保证时间序列的连续性。
为了便于统计，我还增加了一批衍生字段。例如，根据天气描述生成降雨日、雾天、高温日等标记；根据最高气温识别35℃以上的高温天气；根据空气质量等级生成优良天气标记；根据风向、风力组合统计风场特征。这些字段不一定都要直接展示给用户，但它们会支撑后续的图表计算和业务分析。清洗后的数据写入MySQL，后端再按城市、日期、指标类型进行查询和聚合。
在这个阶段，数据库不仅是"存数据"的地方，也承担了系统稳定运行的基础角色。气候数据表负责存储逐日天气信息，用户表和管理员表负责账号权限，数据维护表用于后台增删改查。这样的设计能让普通用户和管理员的操作边界更加清晰，也方便后续扩展更多城市、更多年份或更多环境指标。
四、AQI预测：用LSTM和GRU做短期趋势判断
除了历史统计，我还加入了AQI预测模块。空气质量本身具有明显的时间序列特征，同一城市的AQI会受到季节、降雨、风场、污染排放等多种因素影响。项目中以某一城市近年AQI序列作为示例，用过去一段时间的AQI变化预测下一阶段的数值趋势。模型层面选择了LSTM和GRU两类循环神经网络进行对比。
LSTM擅长捕捉较长周期的时间依赖，结构中包含输入门、遗忘门和输出门；GRU结构更简洁，只保留更新门和重置门，训练效率更高。为了让两者对比更公平，我在输入窗口、训练集划分、优化器和评估指标上保持一致，重点观察RMSE、MAE、R²和训练耗时。结果显示，两个模型都能跟踪AQI的主要波动趋势，GRU在训练速度上更有优势，误差指标也略微更稳，因此系统最终更适合将GRU作为默认预测方案。
图 3 LSTM与GRU模型训练输出和评估指标
从预测曲线看，模型对常规波动的拟合较好，在AQI突然跃升或短时下降的位置会出现一定偏差。这类突变通常与突发天气过程、局地污染源或短期外部因素有关，仅依靠历史AQI序列很难完全捕捉。后续如果继续升级，可以把风向、降雨、湿度、节假日、污染源等特征一并纳入输入，提高模型对异常波动的识别能力。
图 4 LSTM与GRU预测曲线对比展示
五、系统架构：Flask、MySQL、Pyecharts与ECharts协同工作
系统采用B/S架构，用户只需要通过浏览器访问页面，不需要安装额外客户端。后端由Flask提供路由和接口服务，负责登录验证、Session管理、数据查询、图表页面加载和后台管理请求。前端使用HTML、CSS、JavaScript和Layui完成页面布局与交互，图表展示部分由Pyecharts和ECharts共同承担。
Pyecharts更适合批量生成单页可视化页面。项目中有大量主题图，例如空气质量等级占比、天气类型分布、风向统计、风力等级、城市温差、月度AQI趋势、地图热力图等，如果全部手写前端代码，开发量会很大。使用Pyecharts之后，只需要在Python端完成数据分组和图表配置，就能快速生成HTML页面。ECharts则更适合动态大屏，因为它在多图联动、动画效果、异步数据更新和视觉布局方面更灵活。
MySQL在系统里承担核心数据层。后端接口根据页面需求按日期、城市、AQI、天气类型等条件查询，再把结果封装成JSON返回前端。管理员新增或修改数据后，数据库会同步更新，相关页面也能重新加载最新结果。这种设计让系统不只是一个静态作品，而是具备了基本的数据维护能力。
六、用户侧功能：登录、注册、个人中心与可视化访问
用户模块从登录注册开始。用户注册时填写账号密码，前端先做基础校验，后端再检查用户名是否重复。登录成功后，系统写入Session，记录当前用户状态，并进入可视化主页。主页左侧是多级菜单，按分析主题组织图表入口，用户可以在不同页面之间切换，查看温度、降雨、风向、空气质量等分析结果。
图 5 系统登录与用户注册界面
主界面采用左侧菜单加右侧内容区的布局，符合常见后台系统的使用习惯。用户点击不同菜单后，右侧加载对应图表页面。对于毕业设计或项目演示来说，这种结构的好处很明显：页面数量多但入口清晰，展示内容丰富但不会显得杂乱，老师或评审能顺着菜单看到完整功能。
图 6 用户端可视化主页面展示
个人中心主要提供信息维护和账号安全操作。用户可以完善昵称、邮箱、手机等信息，也可以修改密码。密码修改后系统会清除登录状态，引导用户重新登录，避免旧Session继续有效。截图中涉及个人信息的区域已做模糊处理，保留功能布局和交互效果，避免真实账号信息外泄。
图 7 个人信息维护与账号安全操作展示
七、后台管理：用户、数据与概览
管理员模块是系统完整性的关键。普通用户主要看图和查看个人信息，管理员则要负责系统运行维护。后台提供用户列表分页查询、用户新增、编辑、删除和权限升级功能。管理员可以把普通用户升级为管理员账号，系统会完成身份转换，保证权限管理清晰。
数据维护模块提供完整的增删改查入口。管理员可以按日期、AQI、城市筛选气候数据，也可以手动新增记录、修正异常数据、删除错误条目。所有操作都通过REST风格接口完成，前后端使用JSON交互，操作结果以提示框反馈给用户。对于一个展示型项目而言，后台数据管理往往是体现"系统化"的重要部分，它说明项目不只是几个图表拼接，而是具备实际维护流程。
图 8 后台数据查询、新增、更新与概览展示
八、单页可视化：从空气质量到气候结构的多角度呈现
可视化模块是项目最适合展示的部分。我把图表分成几类：空气质量类、天气类型类、温度变化类、风向风力类、区域地图类和综合趋势类。单页图表的特点是主题明确，每个页面只解决一个问题，例如"广西空气质量等级占比如何""哪些天气类型出现最多""风向主要集中在哪些方向""不同城市的温差差异有多大"。
从整体统计看，广西空气质量以"优"和"良"为主，污染天气占比较低；天气类型中晴、多云和小雨出现频率较高，体现出湿润季风气候特征；风力等级大多集中在1级和2级，说明多数城市风速较温和；风向则受到季风和地形影响，东南风、东北风等方向出现较多。这些结论并不需要用户阅读复杂表格，图表本身就能完成信息传达。
图 9 空气质量、天气类型、风向与风力统计图
地图类图表更适合表现空间差异。平均AQI热力图可以看出各市空气质量的相对高低，晴天统计图能展示不同城市日照条件差异，降雨占比图能反映桂北、桂西和沿海城市的降水结构，高温日数图则直观呈现热压力分布。对于区域气候分析来说，地图比单纯柱状图更有冲击力，也更容易让人理解"城市之间为什么不同"。
图 10 广西各市气候环境指标热力图组合展示
时间趋势类图表则更适合观察季节规律。月度温度曲线呈现明显的夏季高、冬季低，月均AQI呈现冬春偏高、夏季偏低的特征，季度温度分布能进一步看出不同季度的波动范围，风向与风力热力图可以揭示高频风场组合。这些图表共同构成了项目的分析层，让系统从"能看"进一步变成"能解释"。
图 11 月度趋势、季度分布与风向风力关系展示
九、动态大屏：把核心指标集中到一张屏幕上
单页图表适合逐项分析，大屏则适合集中展示。项目中的大屏将累计数据量、平均AQI、优良天数、污染天数等核心指标放在顶部，中间区域展示最新天气数据表和广西地图，左右两侧放置AQI趋势、城市对比、风向关系、温度与空气质量关联等图表。整体视觉采用深色科技风，适合演示、汇报和答辩场景。
大屏的设计重点不是把所有图表堆在一起，而是让不同模块之间形成层次。顶部数字卡片回答"整体情况如何"，中间地图回答"空间差异在哪里"，左侧趋势图回答"时间变化怎样"，右侧关联图回答"哪些因素可能有关"。用户不需要来回切换页面，就能快速获得全局印象。图中顶部项目标题和时间区域已做通用化处理，避免公开发布时泄露原始页面信息。
图 12 气候环境数据动态大屏展示
十、测试与复盘：让项目不止停留在"能打开"
系统完成后，我按模块进行了功能测试。用户模块重点测试注册、登录、Session状态、个人信息更新和密码修改；管理员模块重点测试用户分页、编辑、删除、升级和数据维护；可视化模块逐一打开单页图表和大屏，检查图表是否正常加载、数据是否与数据库一致、提示框和缩放交互是否可用。
性能方面，普通页面加载速度较快，单页图表一般可以在较短时间内完成渲染。对于数据量较大的热力图和大屏页面，我通过减少前端一次性渲染压力、优化数据组织方式等方法做了调整。项目整体更偏向教学展示和原型实践，但架构已经保留了继续扩展的空间，例如接入实时天气API、增加多因子预测、加入地图钻取、引入缓存机制、对爬虫任务做定时调度等。
回头看这个项目，最有价值的地方不是单独某个模型或某张图，而是把数据采集、清洗、存储、分析、预测、可视化和后台管理串成了一条完整链路。很多数据分析项目停在Notebook里，图表做完就结束；这个系统更接近一个可交付的小型Web应用，既能展示数据，也能管理数据，还能把算法结果嵌入实际页面。对于学习Python数据分析、Flask开发、ECharts可视化和机器学习预测的同学来说，它是一个比较适合作为综合练习的项目。
十一、后续可以继续扩展的方向
如果继续打磨，我会优先做四个方向。第一，增加实时数据接口，让历史分析和实时监测结合起来；第二，扩展预测特征，不再只使用AQI序列，而是加入温度、降雨、风向、风力和节假日等多源因素；第三，优化前端交互，让地图支持城市点击、指标切换和时间范围筛选；第四，完善部署方案，把数据库初始化、依赖安装、模型加载和大屏启动整理成更规范的说明，方便别人快速复现。
这个项目适合用于毕业设计、课程设计、数据可视化作品集和Python全栈练习。完整资源中包含数据采集脚本、清洗代码、数据库结构、Flask后台、用户与管理员页面、Pyecharts图表生成脚本、ECharts大屏页面以及AQI预测模型代码。公开展示时我只保留了核心功能和效果图，具体代码细节、数据库脚本和部署流程可以按需要继续整理。
每文一语
把数据做成系统，把系统做成作品，把作品做成经验；真正的成长，往往藏在每一次完整闭环的实践里。