基于Django+MySQL+Python的大气污染源可视分析系统开发实战

这个题目我盯了好一阵子——基于Django、MySQL、Python的大气污染源可视分析系统，看似是个典型的课程设计/毕设项目，但真做起来，里面的坑比想象中多得多。我本就长期用Python做数据分析和Web应用开发，这类“数据采集+存储+可视化”的完整闭环项目也带过不少，今天索性把这个项目的源码结构、设计思路、核心实现和踩坑记录完整拆开，给准备上手或正在做类似系统的人一份能直接参考的实操笔记。

先说清楚这套系统是做什么的。它本质上是一个“污染源数据管理+可视化分析平台”：后端用Django提供数据接口和管理后台，MySQL负责存储监测站点、污染物浓度、污染源企业等结构化数据，前端通过ECharts、地图组件把数据渲染成趋势图、热力图、分布图，最后整合成一个可视分析大屏。适合三类人：一是做环境监测相关课程设计或毕业设计的在校生，二是想快速搭建内部数据看板的运维或业务人员，三是想学Django+MySQL+可视化完整链路开发的Python初学者。

1. 项目整体设计与架构拆解

1.1 系统定位：不只是“增删改查”

很多人在拿到这类题目时，第一反应就是“这不就是个CRUD系统吗，用Django admin就完事了”。如果真这么想，那这个项目做出来充其量是个管理后台，离“可视分析”差得远。

这项目的关键点在“可视分析”四个字。它意味着系统至少要具备三层能力：第一层是数据接入，也就是污染源数据怎么进来——可以是爬虫抓取公开数据、手动上传Excel、或者通过API定时同步；第二层是数据治理，原始数据往往是脏的——缺测、重复、格式不统一，需要在落库之前做清洗；第三层是分析展现，也就是把库里的数据变成图表、地图、排名、趋势，让非技术人员能一眼看懂。

所以我的架构建议是这样划分的：

• 数据层：MySQL存储站点表、污染物监测表、污染源档案表、用户表等
• 服务层：Django ORM做数据访问，配合定时任务做数据同步和清洗
• 应用层：分两个面——面向管理员的系统管理面（站点管理、数据维护），面向分析人员的数据可视面（图表查询、时空分布）
• 展示层：页面用Django模板+Bootstrap打底，图表用ECharts（重点），地图用Leaflet或百度地图ECharts扩展

这个分层不花哨，但足够清晰，更重要的是它让每个部分都可以独立测试和扩展。

1.2 技术选型：为什么是Django+MySQL而不是别的组合

先说Django。它的杀手级优势是自带Admin后台、ORM、迁移机制和认证体系，这四个功能基本覆盖了一个数据管理系统的绝大部分通用需求。相对于Flask需要自己拼装一堆扩展，Django在“开发效率”上确实更省事，尤其适合单人开发的中小型系统。

再看MySQL。虽然PostgreSQL在GIS和JSON处理上更强，但MySQL普及率高、运维资料多、托管方便，对大部分院校和企业环境来说是最稳妥的选择。这里特别提醒一点：如果要做地图点位展示，建议在MySQL 5.7以上版本使用JSON字段存储经纬度，配合ORM的JSONField操作，效率很舒服，不需要额外引入PostGIS。

Python版本建议3.9以上，Django选4.x LTS版本。我试过Django 4.0配Python 3.8也没问题，但既然有新版本，没必要在环境上给自己找不痛快。

1.3 核心模块画出来长什么样

我的源码包里面整体的模块划分大概是这样的：

project/ ├── manage.py ├── config/ # 项目配置目录（settings/urls） ├── apps/ │ ├── stations/ # 监测站点管理 │ ├── pollutants/ # 污染物数据管理 │ ├── sources/ # 污染源档案管理 │ ├── analysis/ # 核心的统计分析和图表接口 │ └── users/ # 用户与权限 ├── templates/ # 页面模板 ├── static/ # 静态资源（js/css/地图插件） ├── scripts/ # 数据采集与清洗脚本（独立于Django运行） └── docs/ # 设计文档和说明文档

模块名称尽量用复数、贴近业务含义，比命名成“xxx_info”“test”之类的规范得多，而且后来维护的时候真的会感谢自己。

2. 数据库设计与数据模型实现

2.1 核心表结构：数据模型是地基

在动手写代码之前，一定要先把数据模型设计清楚。我见过太多人写了一半推翻重来的例子，尤其是污染源监测数据这种“事实表”，一旦字段设计不好，后续做统计查询时就要原地爆炸。

我这套系统里核心的表有5张：

站点表（Station）

站点表是基础表，所有监测数据都要挂在站点下。

污染物监测表（PollutantRecord）

这张表是系统的核心事实表，数据量会快速膨胀。索引设计很重要：(station_id, pollutant_type, monitor_time)三字段联合索引是必须的，否则后面做时间范围查询和关联聚合会慢到怀疑人生。

污染源档案表（PollutionSource）

记录重点排污企业的基本信息、行业类别、排放污染物种类、排放量估算值、坐标位置等。这张表的典型作用是做“点位分布图”，在地图上按企业位置标注出来，点击弹出排放信息。

区域空气质量统计表（AirQualityStat）

用于存储按小时/日汇总后的数据，比如每个城市每天的AQI平均值、首要污染物、优良天数等。这个表是“先聚合、后查询”策略的产物，避免每次都全量扫原始记录做聚合。

用户与角色表

Django自带User模型，加一个Profile扩展角色字段即可。系统里分管理员、数据录入员、只读访客三类。没必要做复杂的RBAC，用Django的Group+Permission已经足够。

2.2 ORM模型实现的关键技巧

Model层建议直接上图，核心的模型类长这样：

# apps/stations/models.py from django.db import models class Station(models.Model): name = models.CharField(max_length=128, verbose_name="站点名称") code = models.CharField(max_length=32, unique=True, verbose_name="站点编码") city = models.CharField(max_length=64, verbose_name="所在城市") longitude = models.FloatField(verbose_name="经度") latitude = models.FloatField(verbose_name="纬度") address = models.CharField(max_length=255, blank=True, verbose_name="详细地址") status = models.BooleanField(default=True, verbose_name="是否启用") class Meta: db_table = "station" verbose_name = "监测站点" indexes = [ models.Index(fields=["city"], name="idx_station_city"), ]

# apps/pollutants/models.py class PollutantRecord(models.Model): POLLUTANT_TYPES = [ ("AQI", "空气质量指数"), ("PM25", "PM2.5"), ("PM10", "PM10"), ("SO2", "SO2"), ("NO2", "NO2"), ("CO", "CO"), ("O3", "O3"), ] station = models.ForeignKey(Station, on_delete=models.CASCADE, related_name="records") pollutant_type = models.CharField(max_length=16, choices=POLLUTANT_TYPES, db_index=True) value = models.FloatField(verbose_name="监测值") monitor_time = models.DateTimeField(verbose_name="监测时间") data_source = models.CharField(max_length=64, default="api", verbose_name="数据来源") class Meta: db_table = "pollutant_record" ordering = ["-monitor_time"] indexes = [ models.Index( fields=["station", "pollutant_type", "monitor_time"], name="idx_pollutant_query", ), ]

注意几个细节：

• db_table单独指定，而不是让Django自动生成app_model形式。理由是SQL脚本给到别人时，表名越简洁越好对接。
• on_delete=models.CASCADE意味着删站点会级联删除监测数据。实际业务中这很危险，但课程设计和演示系统无所谓。如果上线真实系统，建议改成PROTECT，强制让你先处理数据再删主表。
• 复合索引里的字段顺序，务必把等值查询字段放前面，范围字段放最后。SQL里WHERE station_id= ? AND pollutant_type=? AND monitor_time BETWEEN ? AND ?是最常见的查询模式，索引顺序就这么排。

3. 核心功能实操：从项目创建到可视化大屏

3.1 环境搭建：半小时跑起项目基础

没有特殊环境要求的Linux/macOS/Windows都可以，提前装好Python 3.9+和MySQL 5.7+。

先用conda或venv创建虚拟环境，防止污染系统Python环境：

python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install django mysqlclient

这里重点说mysqlclient这个库。Windows下经常装不上，因为缺少微软编译工具。两个解法：要么装pymysql然后在项目的__init__.py里做兼容，要么直接使用预编译的whl包。我个人建议Windows用户直接上pymysql，部署Linux服务器时再换回mysqlclient，毕竟生产环境性能更好。

注意pymysql的兼容代码要放在项目同名目录的__init__.py里：

import pymysql pymysql.install_as_MySQLdb()

这个文件是全项目最先加载的地方，用它做入口最干净。

创建项目和应用：

django-admin startproject config . python manage.py startapp stations python manage.py startapp pollutants python manage.py startapp sources python manage.py startapp analysis

settings.py 里核心配置有这些坑要避：

• ALLOWED_HOSTS在DEBUG=True时留空即可，部署时改成服务器IP或域名；
• DATABASES配置MySQL时，记住OPTIONS里设置charset='utf8mb4'，否则中文和emoji写入会报错或不显示；
• TIME_ZONE建议设成Asia/Shanghai，USE_TZ保持True，但入库前统一转naive时间。我自己踩过时区坑，后面单独说。

3.2 数据导入与清洗：别让脏数据毁掉图表

我源码里带了一个scripts/import_data.py，作用是从CSV和Excel文件批量导入监测数据到MySQL。代码逻辑不复杂，核心是先校验、再清洗、最后批量入库：

# scripts/import_data.py import pandas as pd import os os.environ.setdefault("DJANGO_SETTINGS_MODULE", "config.settings") import django django.setup() from apps.pollutants.models import PollutantRecord from apps.stations.models import Station def clean_value(val): """清洗监测值，非数字/负数返回None""" if pd.isna(val): return None try: fval = float(val) return fval if fval >= 0 else None except (TypeError, ValueError): return None def import_records(file_path, station_code, pollutant_type): df = pd.read_csv(file_path) station = Station.objects.get(code=station_code) bulk_list = [] for _, row in df.iterrows(): value = clean_value(row.get("value")) if value is None: continue bulk_list.append(PollutantRecord( station=station, pollutant_type=pollutant_type, value=value, monitor_time=row["monitor_time"], data_source="csv_import", )) # 用 bulk_create 批量插入，速度远超逐条 save() PollutantRecord.objects.bulk_create(bulk_list, batch_size=1000) print(f"成功导入 {len(bulk_list)} 条记录")

这段代码有几个值得展开的细节：

批量插入：逐条.save()在10万条数据面前等于自杀，bulk_create一次性插入可以快几十倍。但注意不要开启ignore_conflicts，否则重复数据会静默丢失，你还不知道哪错了。

批量入库前先查重：如果重复执行导入脚本，会产生大量重复记录。我在实际项目里加了去重条件，导入前用query.exists()检查同站点同时间同类型是否已有记录，有则跳过。字段多了之后速度会下降，但正确性优先。

pandas读取时间字段的格式问题：大部分CSV里的时间都是文本，直接用pd.to_datetime转换，转换失败整行丢弃，这在清洗逻辑里要体现出来。宁缺毋滥，留空数据的记录比留错数据好处理得多。

3.3 图表接口：从ORM到ECharts的完整链路

这个系统的前页面核心是图表。图表展示不该在前端发Ajax拿原始数据再自己拼数组，而应该让后端返回“已经按前端图表要求整形好”的数据结构，前端只负责渲染。

拿“某站点近24小时PM2.5浓度变化曲线”这个场景举例：

后端视图代码：

# apps/analysis/views.py from django.db.models import Avg from django.http import JsonResponse from django.utils import timezone from datetime import timedelta from apps.pollutants.models import PollutantRecord def pm25_trend(request, station_id): station_id = int(station_id) start_time = timezone.now() - timedelta(hours=24) records = ( PollutantRecord.objects .filter(station_id=station_id, pollutant_type="PM25", monitor_time__gte=start_time) .order_by("monitor_time") .values("monitor_time", "value") ) data = { "times": [r["monitor_time"].strftime("%Y-%m-%d %H:%M") for r in records], "values": [r["value"] for r in records], } return JsonResponse(data)

前端ECharts部分（核心配置）：

// static/js/trend.js $.getJSON('/api/station/1/pm25/trend/', function(res) { chart.setOption({ tooltip: { trigger: 'axis' }, xAxis: { type: 'category', data: res.times, axisLabel: { rotate: 45 } }, yAxis: { type: 'value', name: 'μg/m³' }, series: [{ name: 'PM2.5', type: 'line', smooth: true, areaStyle: { opacity: 0.2 }, data: res.values }] }); });

用户直观感受到的“图表渲染”，背后是“ORM查询→JsonResponse→前端配置”的链路，哪一环断了都会黑屏。对于小白来说，后端返回的数据格式一定要先打印出来看一眼，避免结构对不上导致前端undefined。

3.4 污染源地图分布：经纬度加ECharts scatter

地图分布是污染源可视分析的点睛之笔。合理的实现方式是用ECharts的scatter图层覆盖在一张中国地图底图上：后端返回污染源列表（含名称、经纬度、主要污染物、排放量），前端注册地图JSON后绘制散点。

需要特别提醒的是经纬度坐标系的转换问题。ECharts地图默认使用GeoJSON坐标，如果你拿到的数据是GCJ-02（火星坐标系，比如通过地图API拾取的坐标），直接叠加到标准地图上会偏移几十到几百米，肉眼不易察觉但打印到图上点位会偏移。稳妥的办法：数据入库前统一用一个小工具函数做坐标系转换，或者干脆在说明文档里注明“本项目地图底图使用WGS-84，坐标来源需保持一致”。

3.5 管理后台：Django Admin的二次定制

Django Admin默认就能用，但原生的列表页信息密度低，搜索和筛选也不够顺手。强烈建议至少做三件事：

• 注册模型时用list_display展示核心字段，比如站点的名称、城市、经纬度、启用状态；
• 对PollutantRecord设置list_filter = ["pollutant_type", "monitor_time", "station"]，这样在后台按污染物类型快速过滤；
• 给monitor_time加date_hierarchy，可以在后台按日期逐级下钻。这是Django Admin里利用率最低但最好用的功能。

@admin.register(PollutantRecord) class PollutantRecordAdmin(admin.ModelAdmin): list_display = ("station", "pollutant_type", "value", "monitor_time", "data_source") list_filter = ("pollutant_type", "monitor_time") date_hierarchy = "monitor_time" search_fields = ("station__name",)

加这几行基本上就是“开箱即用”的完整数据管理入口了。

3.6 大屏页面的组装

大屏的本质是“多个图表组件的组合布局”，不需要炫技。我的做法是做一个dashboard.html模板，顶部放标题和当前时间，中间区域是三列布局：左侧放污染源Top10排名、中间放核心污染物实时数值和AQI仪表盘、右侧放24小时趋势图，下方整行放地图点位分布。

页面结构虽然看起来内容多，但每个模块都是一个独立的Ajax请求，互不阻塞。注意页面加载时一次性发起多个请求，避免串行等待导致首屏空白。

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

4.1 MySQL连接问题和时区问题

这是出现频率最高的第一个坑。症状是连接时报Can't connect to MySQL server或者Access denied。

排查路径：第一，确认MySQL服务已启动；第二，确认settings里HOST/PORT/USER/PASSWORD没错；第三，注意MySQL默认只监听3306端口，如果是云服务器，安全组一定要放行。如果用的是本机MySQL，检查是不是用了localhost但MySQL配置了skip-networking。

时区问题更隐蔽。表现是Django页面里写入的时间，数据库里存的值比实际时间早了8小时。原因在于Django的USE_TZ=True会把时间按UTC存储，读取时再转成本地时区，但如果你在代码里用datetime.now()而非timezone.now()，写入的naive时间会被当作UTC处理，一转换就错位了。解决方法是统一用timezone.now()，并在settings.py里配置TIME_ZONE="Asia/Shanghai"。

4.2 大数据量查询慢：聚合表与缓存不能省

当监测数据过百万时，原来的图表接口响应会明显变慢。排查方法是用EXPLAIN看SQL执行计划，你会发现全表扫描。解决思路有两层：第一层是索引，搞清查询条件后建复合索引；第二层是预聚合，即建一张按天/小时聚合的统计表，页面请求时直接查统计表，而不是实时聚合明细数据。

我实测过一组数据：100万条明细记录，实时AVG聚合响应大概在2秒左右，而查预聚合表响应降到80毫秒。这个数量级差异直接决定系统可用性。

4.3 前端图表横轴时间点太密集

ECharts默认会把所有时间点都渲染到横轴上，24小时数据还好，如果是30天逐小时数据，标签就会挤成一团。网上的热搜词“python画图横坐标太密集”其实问的也就是这个。

解法不复杂：一是用axisLabel.interval控制标签间隔；二是让ECharts自动计算，设置axisLabel: { interval: 'auto', rotate: 45 }；三是做数据降采样，后端按小时/天聚合后传给前端。三种方式我建议优先考虑第三种，因为后端给的数据量小了，前端渲染整体就流畅。

4.4 定时任务：如何让数据每天自动更新

数据同步不要靠手动点击，生产环境务必配置定时任务。Django生态里最成熟的是django-celery-beat，但初次上手配置略重。

还有一种轻量方案：在Linux的crontab里写一行命令，定时执行数据同步脚本。比如每天凌晨2点同步前一天的数据：

0 2 * * * cd /usr/local/project && venv/bin/python scripts/import_data.py >> logs/import.log 2>&1

好处是独立于Web进程，脚本崩了不会影响系统；坏处是日志和监控要自己管。课程设计用crontab足够了。

4.5 文档里必须覆盖的内容

“源码+文档”这种交付项目，文档的重要性不亚于代码。系统性的文档至少包括三份：部署文档（从零开始的安装步骤）、设计文档（架构图、数据模型、核心流程）、使用说明（管理员和普通用户的操作指引）。部署文档里最容易被忽略的是MySQL初始化脚本——需要提前创建好数据库并导入结构SQL。README里一定写清楚所有坑，比如pymysql安装、编码设置、时区配置，避免后来的人重新踩一遍。

5. 后续扩展的两点建议

这个系统做完基础版之后，还有两条很自然、很值得做的演进路线。

第一条路线是“预测方向”。在历史数据累积到一定程度后，可以用时间序列模型（比如Prophet、LSTM）对PM2.5浓度做短期预测，预测结果叠加到现有的趋势图里，从“看已经发生了什么”升级成“看下一小时大概率发生什么”。技术选型上建议先跑Prophet试试效果，因为它的优势是”不需要深度调参、原生支持节假日效应影响”等，对非气象专业的开发者很友好。在Django里调用模型时，注意把模型文件放在固定目录，并提供预加载和缓存机制，否则每次请求都把模型加载一遍，接口会慢到不可接受。

第二条路线是“告警方向”。利用Django的异步任务或者接入外部消息渠道，设置浓度阈值告警。比如某个站点的PM2.5超过200微克每立方米时，自动向管理员手机推送告警消息。如果在测试环境，直接集成微信公众号模板消息或者邮件通知即可。这个功能不会增加太多开发量，但会让系统从“展示型”变成“可操作型”，实用价值翻倍。

还有一个小技巧：在做前端之前，把数据库里需要展示的统计口径先梳理清楚，用什么时间粒度（实时/小时/日/月）、按什么维度聚合（站点/城市/污染物类型），拿Excel或SQL把结果跑出来验证一遍，再写接口。否则图表做出来后才发现口径不对，改后端事小，改前端交互逻辑就烦了。

我个人的体会是，这类全栈项目最容易出彩的地方不在单个技术水平多高，而在“链路完整”——从数据采集到可视化呈现，每一步都走得稳，用户拿到系统后能顺畅地看到有价值的信息，就是成功。剩下那些细节上的优化，都是在真实使用中一点点打磨出来的。如果你正在做类似题目，把上面这些点一个个落实，你的交付质量会超过大多数同类项目。