1. 项目背景与整体设计1.1 海洋气象数据可视化到底在解决什么问题我最早接触海洋气象数据是在一个沿海城市的观测站项目里。当时站里的监测员每天要盯几十张Excel表把温度、盐度、风速、气压、浪高这些数据翻来覆去地看遇到台风过程或者寒潮过程几个站点的数据要拼在一起对比工作量大不说还特别容易看漏关键变化。后来我意识到海洋气象数据有一个很突出的特点维度多、时间连续性强、空间分布散。一张表里几十个字段光靠数字根本看不出趋势必须把数据“画”出来。这就是我做这个平台的初衷用Django做后端数据服务用ECharts做前端图表渲染把海洋气象观测数据变成一套可交互的可视化平台。这个平台能解决三个层面的问题一是把多站点的长期观测数据统一管理起来不再让数据散落在表格里二是通过折线图、柱状图、饼图、地图等图表让变化趋势、风向规律、空间分布一目了然三是通过实时推送能力让自动化观测站的新数据能够自动刷新到前端页面不用手动刷新浏览器。这个项目适合谁如果你是刚学完Django基础、想找一个实战项目的开发者或者你在气象、海洋、环保这类行业做数据相关的工作再或者你想把“后端接口 前端可视化”这条链路彻底跑通的初学者那这篇文章的思路和踩坑记录都应该能帮到你。我会把从数据库设计到图表渲染的完整过程都过一遍重点说的是那些文档里查不到、只有实际动手才会遇到的细节。1.2 平台功能模块与整体架构平台的功能我大致分成了五个模块这也是这类系统最常见的划分方式数据总览模块展示最近24小时各站点的关键要素用仪表盘、卡片和动态图表快速呈现整体状态。时序分析模块按站点、按时间段查询温度、盐度、气压等要素画折线图和面积图支持多要素对比。统计对比模块用柱状图对比不同站点的降水量用饼图分析风向频率用雷达图对比多站点多要素的总体特征。空间分布模块在中国地图或区域地图上标注站点位置用散点图或热力图展示空间分布规律。实时监控模块通过 WebSocket 接收观测站新数据前端页面自动更新最新观测值并触发预警提示。架构层面我采用的是前后端不分离的传统Django项目结构。页面由 Django 模板渲染图表数据从接口异步获取这样既省去了搭建前端工程的成本又能保持代码结构清晰。整个请求链路大概是浏览器加载模板页面页面里的 JavaScript 通过 Ajax 请求 Django 写的 JSON 接口接口从 PostgreSQL 里查数经过序列化返回前端最后由 ECharts 根据返回数据渲染图表。实时监控部分单独走 WebSocket由 Django Channels 处理。2. 技术选型的思考与权衡2.1 为什么是 Django 而不是 Flask 或 FastAPI先说我为什么盯上Django。其实我早期写后端用过 Flask轻量确实轻量但一个项目要加认证、加后台管理、加数据库迁移Flask 需要你自己去拼拼图。Django是“全家桶”自带ORM、Admin 后台、认证系统、模板引擎对一个要做完整平台的项目来说能省掉非常多的重复劳动。有人可能会问那 Python3 都用上了为啥不用 FastAPIFastAPI 的异步性能和接口文档自动生成确实强但这类海洋气象可视化平台核心复杂度不在接口并发而在数据建模、数据清洗、图表渲染这些地方。Django 的 ORM 在处理复杂查询、数据聚合时非常顺手Admin 后台还能直接让业务人员录入和维护站点信息这对没有专职开发的业务部门来说是一大优势。如果非要给个结论追求快速交付、业务逻辑复杂、需要后台管理、团队熟悉 Django 的直接选 Django如果接口性能是最大瓶颈、前端完全分离且有专门运维再考虑 FastAPI。我这个项目里数据量属于中等规模Django 单实例完全扛得住。2.2 为什么是 ECharts 而不是 D3 或 Highcharts前端图表库这块我几乎没犹豫就选了ECharts最新版本已经到5.x了。原因很简单ECharts 是开源库免费图表类型足够丰富开箱即用。我需要折线图、柱状图、饼图、雷达图、地图、热力图它全都支持。对比一下其他方案Highcharts 功能也强大但商业使用要买授权个人项目无所谓、公司项目就要走流程了D3.js 自由度极高但学习曲线陡峭从数据到图表的每一步几乎都要自己手动操作开发周期根本不可控Plotly 在科学计算领域表现不错但与 Django 模板的配合不如 ECharts 灵活。ECharts 还有一个很实用的特点它是纯 JavaScript 方案直接引入一个 JS 文件就能用不像一些图表库需要配合特定框架。我在项目里甚至没有用前端构建工具直接在 Django 模板里引用了本地静态文件做了简单的封装就可以用了。中文文档也写得比较细遇到不会配置的图表查一下官方的在线示例基本能解决。2.3 实时推送与权限管控的选型如果你只是做一个展示型可视化平台用 Ajax 轮询就够了但我的平台要考虑自动化观测站的实时数据推送场景。这类站点的数据五分钟一条如果每五分钟让用户自己刷新页面体验会很差。我选择了Django Channels来实现 WebSocket因为它是 Django 官方生态里的异步方案与 Django 的认证系统集成得比较好。权限这块Django 自带的用户认证和RBAC基于角色的访问控制已经覆盖了大部分需求。我建了三个角色管理员、业务人员、访客分别对应不同数据范围的查看权限。这里我踩过一个坑Django 的默认权限是基于模型的如果想控制某个 API 只返回部分站点数据还是需要自己在视图层再做一次过滤。3. 数据模型与数据库设计3.1 海洋气象数据特点分析老话说得好“数据模型设计好了后面至少少改一半代码”。海洋气象观测数据有几个明显特点设计时必须优先考虑要素种类固定但值域跨度大温度可能是零下几度到三十几度气压可能是950到1050百帕风速可能是0到40米每秒每个要素都需要有明确的量纲和物理单位。时间序列为主绝大多数查询都是“某站点某段时间的观测值”所以时间字段必须单独建索引。缺测情况普遍传感器漂移、通信中断、海况恶劣都可能导致某个时次的数据缺失。在业务上缺测和0值完全是两回事必须用特殊值或NULL区分。数据只追加、极少修改观测数据一旦入库基本不会再改删除操作也主要发生在数据质量控制和清理阶段。考虑到这些特点我把表结构设计成“站点维度数据维度”分开的形式避免把所有要素塞进一张宽表里。3.2 核心表结构设计我建了三张核心表站点信息表、观测数据主表、观测数据明细表。站点信息表比较简单站点编码唯一、站点名称、经度、纬度、站点类型海岛站、海岸站、浮标站、所属区域、海拔高度、启用时间。这个表也通过 Django Admin 维护业务人员自己就能加站点。观测数据这块我一开始想的是把温度、盐度、风速等四五十个要素都建成字段后来发现不对。一是字段太多、大部分查询根本用不到二是以后要加一个要素还得改表结构。所以最终我采用了“主表明细表”的 EAV实体-属性-值风格设计观测数据主表记录观测站点、观测时间、数据来源、数据质量标识。观测数据明细表记录主表外键、要素编码temperature、salinity、wind_speed之类的字符串、要素数值、要素单位、质量标识。这种设计看起来多了一次关联查询但在实际使用中配合 PostgreSQL 的索引性能完全可以接受。而且业务人员添加新观测要素时只需要在要素字典表里加一条记录不用改代码。from django.db import models class Station(models.Model): code models.CharField(站点编码, max_length32, uniqueTrue) name models.CharField(站点名称, max_length64) longitude models.FloatField(经度) latitude models.FloatField(纬度) station_type models.CharField(站点类型, max_length16, choices( (island, 海岛站), (coast, 海岸站), (buoy, 浮标站), )) region models.CharField(所属区域, max_length64, blankTrue) is_active models.BooleanField(是否启用, defaultTrue) class Meta: db_table station verbose_name 观测站点 verbose_name_plural 观测站点 class Observation(models.Model): station models.ForeignKey(Station, on_deletemodels.CASCADE, verbose_name站点) obs_time models.DateTimeField(观测时间, db_indexTrue) source models.CharField(数据来源, max_length32, defaultauto) quality_flag models.CharField(质量标识, max_length8, defaultgood) class Meta: db_table observation ordering [-obs_time] class ObservationElement(models.Model): observation models.ForeignKey(Observation, on_deletemodels.CASCADE, verbose_name观测记录) element_code models.CharField(要素编码, max_length32, db_indexTrue) element_value models.FloatField(要素数值, nullTrue, blankTrue) unit models.CharField(单位, max_length16, blankTrue) class Meta: db_table observation_element关于 on_delete 参数我要多说一句。明细表这里的on_deletemodels.CASCADE是有意的观测记录被删除时明细数据一起删掉不会留下孤儿数据。后面我会单独说清洗数据时删除对象的大坑。3.3 数据清洗与批量入库数据入库不是直接save()就完事的。海洋观测数据里经常出现重复上报和明显越界的问题我在入库前加了一个清洗步骤先按“站点观测时间”去重再进行要素的值域校验超出物理范围的值统一转换成 NULL 并标记为可疑。批量入库我用的方法是 Django ORM 的bulk_create()一次性把几千条记录写入数据库比循环单条插入快非常多。实测插入5000条观测数据循环插入可能要十几秒bulk_create基本上秒级完成。要注意的是bulk_create不会触发模型的save()方法所以如果有自动填充字段的逻辑需要先手动处理好再入库。def import_observations(station_code, data_list): station Station.objects.get(codestation_code) obs_list [] element_list [] for item in data_list: obs Observation( stationstation, obs_timeitem[time], sourceitem.get(source, auto), ) obs_list.append(obs) Observation.objects.bulk_create(obs_list) # 再批量插入明细 obs_objs Observation.objects.filter( stationstation, obs_time__in[i[time] for i in data_list] ).order_by(obs_time) for obs, item in zip(obs_objs, data_list): for key, value in item[elements].items(): element_list.append(ObservationElement( observationobs, element_codekey, element_valuevalue, )) ObservationElement.objects.bulk_create(element_list)这里有个小技巧因为主表里obs_time加了索引查询已经插入的记录再做关联速度很快。你如果不在入库前做去重后面排查数据翻倍的问题时会非常痛苦。4. 后端接口与数据服务实现4.1 Django 工程结构与 App 划分Django 项目创建我之前也纠结过后面发现一个原则功能边界清晰就按业务口径划分 App不要按“前端/后端”划分。这个平台我建了三个 Appaccounts用户认证、角色权限。stations站点管理和观测数据入库。dashboard可视化页面的视图和 API。新建 App 的命令很简单但新手容易漏掉的是创建之后要立刻到settings.py的INSTALLED_APPS里注册否则 Django 根本不会创建对应的数据表。这一步除了注册还要把模板目录、静态文件目录配置好不然页面渲染和图片加载都会出问题。我在第七章会详细说静态文件的坑这里先不展开。4.2 API 接口设计与实现接口我使用的是 Django 自带的JsonResponse没有引入 Django REST Framework。原因是平台接口数量不大且本身需要借用模板渲染后续页面如果接口很多、字段嵌套复杂再引入 DRF 也不迟。选择JsonResponse的好处是代码直观、无额外依赖返回的数据结构完全可控前端拿到的 JSON 是什么样的我一眼就能看出来。核心有三个接口GET /api/stations/返回所有启用站点的列表前端用来初始化地图和站点下拉框。GET /api/obs/trend/?stationxxxstart...end...elementstemperature,salinity返回指定站点在时间段内的要素时序数据。GET /api/obs/summary/?start...end...返回各站点的统计数据用来渲染柱状图和饼图。时序接口是查询最频繁的我特意做了一层时间参数解析。海洋观测数据统一使用 UTC 时间存储但业务人员习惯看本地时间接口里我用timezone.localtime转换一次避免图表上出现8小时偏移。还有一件事必须做参数校验。别在前端把参数传错了后端直接报500。我的做法是在视图函数入口先解析并校验日期格式和站点编码有问题就返回带error字段的JSON而不是抛异常。def trend_data(request): station_code request.GET.get(station, ) start request.GET.get(start, ) end request.GET.get(end, ) elements request.GET.get(elements, temperature) if not station_code or not start or not end: return JsonResponse({error: 缺少必要参数}, status400) try: start_dt parse_datetime(start) end_dt parse_datetime(end) except ValueError: return JsonResponse({error: 日期格式错误}, status400) station Station.objects.filter(codestation_code, is_activeTrue).first() if not station: return JsonResponse({error: 站点不存在}, status404) obs_qs Observation.objects.filter( stationstation, obs_time__range[start_dt, end_dt], ).prefetch_related(elements).order_by(obs_time) result {time: [], elements: {}} for obs in obs_qs: result[time].append(obs.obs_time.astimezone(timezone.get_current_timezone()).strftime(%Y-%m-%d %H:%M)) for elem in obs.elements.all(): if elem.element_code in elements.split(,): result[elements].setdefault(elem.element_code, []).append(elem.element_value) return JsonResponse(result)4.3 性能优化缓存、聚合与索引时序数据越积越多之后查询速度明显会下降。我的优化思路是按优先级排了三步。第一步是建复合索引。Django 模型里定义了db_indexTrue的单列索引但在我的查询模式下(station_id, obs_time)的复合索引更能命中查询条件。直接在Observation的 Meta 里加index_together [(station, obs_time)]。第二步是接口缓存。对于柱状图、饼图这类统计类接口数据变化频率不高我用 Django 的缓存框架把结果缓存五分钟。时间序列接口因为有实时性要求没有加缓存但做了数据量限制默认只返回最近30天的数据防止一次查询拉太多数据把接口拖垮。第三步是在前端做数据降采样。当请求时间跨度超过90天折线图上的点会非常多即便接口返回全部数据前端渲染也会卡。我在后端判断时间跨度如果超过阈值就按小时或天做聚合返回聚合后的均值或极值。这样图表上显示的是趋势而不是每一个原始点。聚合查询用 ORM 写起来也不难from django.db.models import Avg daily_stats ObservationElement.objects.filter( observation__stationstation, observation__obs_time__range[start_dt, end_dt], element_codetemperature, ).values(observation__obs_time__date).annotate( avg_valueAvg(element_value) ).order_by(observation__obs_time__date)5. ECharts 可视化核心实现5.1 图表配置的基本套路先说一个所有 ECharts 图表的共同套路你不会配置某个图表时先去官方在线示例里找到类似的图改数据看效果再把 option 结构套到自己的项目里。我刚开始接触时也是这么干的ECharts 的配置项很多全部背下来不现实把握好xAxis、yAxis、series三个核心结构其他都是增删改查的问题。ECharts 官方把常用配置叫 option一个最简单的折线图大概是const chart echarts.init(document.getElementById(trendChart)); chart.setOption({ tooltip: { trigger: axis }, legend: { data: [温度] }, xAxis: { type: category, data: timeList }, yAxis: { type: value, name: ℃ }, series: [{ name: 温度, type: line, data: valueList, smooth: true }] });这里的核心是把接口返回的数据填充进去。如果你的页面在setOption时还没有拿到数据可以先设置一个空配置等 Ajax 成功回调里再setOption。我建议写一个initCharts()函数统一初始化所有图表然后在数据回调里单独更新。5.2 折线图、柱状图、饼图实战折线图是最常用的海洋气象要素几乎都是连续变化的时间序列。实践中我发现了几个值得注意的点双Y轴温度和盐度量纲差异巨大一个图表里要显示两组数据时必须用双Y轴否则数值小的要素线条会被压成一条直线。ECharts 里加yAxisIndex: 1就可以了。x轴刻度当数据点多时默认的间隔会导致标签挤成一团。设置xAxis.axisLabel.interval为Math.ceil(timeList.length / 10)只显示大约10个刻度页面会立刻清爽很多。面积图渐变色这是我常用的一个视觉增强手段设置lineStyle的颜色再给areaStyle配置渐变让趋势图看起来更立体。ECharts 5 里渐变写法比较固定areaStyle: { color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [ { offset: 0, color: rgba(54, 162, 235, 0.6) }, { offset: 1, color: rgba(54, 162, 235, 0.05) } ]) }柱状图在统计模块里用来对比各站点同一要素的均值或总量。柱状图的渐变色和折线图类似区别在于渐变方向更常用垂直方向让柱子底部颜色浅、顶部颜色深或者反过来。饼图我用在风向频率统计上把360度按16方位切分统计每个方位出现的频率。这里有个细节ECharts 饼图默认扇区颜色比较跳我直接指定了一套适合海洋主题的色板比如用蓝色系代表北风、橙色系代表南风这样业务人员扫一眼就能定位主导风向。5.3 中国地图与空间分布可视化做站点空间分布时我用到了ECharts 中国地图。要注意的是ECharts 从5.0开始不再内置地图GeoJSON数据需要额外加载地图数据文件。当时我在网上找了不少JSON资源最后使用的是一个偏简化的中国地图GeoJSON。如果你只需要某个省份的站点分布也可以只加载对应区域的地图这样体积更小、加载更快。地图的绘制模式我建议用geoscatter的组合用geo显示地图轮廓用scatter系列在站点经纬度位置画散点。这样做的好处是散点完全独立数据更新时只需要重新设置散点系列的data地图本身不需要重新加载。option { geo: { map: china, roam: true, itemStyle: { areaColor: #e8e8e8, borderColor: #999 } }, series: [{ type: scatter, coordinateSystem: geo, data: stationData.map(item ({ name: item.name, value: [item.longitude, item.latitude, item.value] })), symbolSize: function(val) { return Math.max(6, val[2] / 100); }, itemStyle: { color: #1a8cd8 } }] };如果站点密集散点之间会互相压住。解决方法是把symbolSize调小并在tooltip里显示站点的详细名称和数据用户鼠标悬停时才能看得清。还有一种方案是做聚类或者只显示当前筛选条件下的站点但总体思路是地图是空间感展示具体数值交给 tooltip 和时间序列图去做。5.4 动态数据更新与配色细节动态更新是可视化平台和静态图表最大的区别。页面上所有图表在初始化时都要有一个“默认空态”或者“加载中”状态然后在数据接口返回后调用chart.setOption({...}, true)来更新。第二个参数true表示不合并之前的配置直接把数据替换掉这是动态刷新时的关键点不加这个参数会出现新数据叠加旧数据的现象。配色这块我踩过几次坑才总结出经验海洋气象平台的图表颜色尽量选用低饱和度的蓝色系和绿色系表示常规要素用红色或橙色表示预警信息。统一的颜色语言能让用户形成直觉看到红色就知道是警报或极端值而不是花里胡哨的渐变色。ECharts 默认的颜色主题偏彩色系我一般会在页面初始化时调用echarts.registerTheme或者直接在每个图表的color数组里指定一套全局色板。6. 实时数据推送方案6.1 WebSocket 场景与方案选择可视化平台做到一定阶段你一定会遇到一个需求后台数据库有新的观测数据前端页面要自动更新用户不能总是手动刷新。普通的 HTTP 接口只能由客户端发起请求服务端不能主动推送数据。要实现“后台有数据、前端立刻知道”的效果常见方案有两种一种是前端定时轮询每隔几秒用 Ajax 请求一次接口。实现简单但如果数据更新频率低、请求频繁服务端会有大量无效查询如果数据更新频率高轮询间隔又不好控制可能看到的数据总是滞后。另一种是WebSocket客户端和服务端建立一条持久连接服务端可以随时推送消息给前端。这正是我说的实时监控场景最合适的方案。在 Django 生态里django-channels是把 WebSocket 接入 Django 最自然的工具它把 WebSocket 的处理逻辑抽象成类似视图的 consumer并且能复用 Django 的认证和信息模型我能直接用现有的用户系统鉴权不用另搞一套。6.2 Django Channels 实现服务端推送接入 Channels 需要做几件事安装channels、在settings.py里把ASGI_APPLICATION配置指向asgi.py、在项目根下建routing.py定义路由然后写 consumer 来处理连接和消息。我的实时监控功能逻辑是这样的观测数据入库后触发一个信号服务端通过 channel layer 向对应组推送最新数据所有订阅了该组的前端页面都会收到消息然后调用 ECharts 的setOption更新图表。# consumers.py import json from channels.generic.websocket import AsyncWebsocketConsumer class ObservationConsumer(AsyncWebsocketConsumer): async def connect(self): await self.channel_layer.group_add(observations, self.channel_name) await self.accept() async def disconnect(self, close_code): await self.channel_layer.group_discard(observations, self.channel_name) async def observation_message(self, event): await self.send(text_datajson.dumps(event[data]))服务端往这个组里推送消息的方式在 Django 视图或信号处理器里调用async_to_sync(channel_layer.group_send)。from asgiref.sync import async_to_sync from channels.layers import get_channel_layer def notify_new_observation(station_code, obs_time): channel_layer get_channel_layer() async_to_sync(channel_layer.group_send)( observations, { type: observation_message, data: { station: station_code, obs_time: obs_time, message: new_observation } } )这里要注意group_send必须在异步上下文或者通过async_to_sync包装调用直接在普通同步视图里调用会报错。我一开始没加async_to_sync结果在信号处理器里直接写channel_layer.group_send(...)运行时才知道这个坑。6.3 前端接收与异常处理前端我用原生 WebSocket 来接收没有引入额外的库避免加重页面依赖。核心逻辑是页面加载后建立连接收到消息后解析 JSON判断站点编码是否和当前筛选的站点匹配匹配了才更新时间序列图数据并重新请求接口。const ws new WebSocket(ws:// window.location.host /ws/observations/); ws.onmessage function(event) { const data JSON.parse(event.data); if (currentStation data.station) { loadTrendData(); showToast(收到新观测数据); } }; ws.onclose function() { // 断线重连延迟3秒重新建立连接 setTimeout(connectWebSocket, 3000); };断线重连是我特别强调的经验。WebSocket 连接经常因为服务重启、网络抖动断开如果前端不做重连逻辑用户会不知不觉看不到新数据。我加了心跳机制每30秒发一个 ping 消息服务端返回 pong连续几次收不到 pong 就主动重连。这个逻辑虽然简单但极大提高了实时监控模块的稳定性。还有跨域问题。如果你的 Django 和前端服务不在同一个域名下WebSocket 握手同样受到跨域限制需要在 Channels 中间件里配置允许的来源。我在实际部署时为了省事直接用同一个域名下部署 Django 和静态页面绕开了这个问题。7. 常见问题与排查实录7.1 静态文件与 img 标签不显示这个问题我在 vscode 里写代码时遇到过花了我快半天时间排查。页面模板里写了img src/static/img/logo.png但浏览器就是显示不了控制台报404。根本原因有几个第一STATIC_URL 和 STATICFILES_DIRS 配置不对。我只在settings.py里写了STATIC_URL /static/但没有把自定义的静态文件目录加进STATICFILES_DIRS。Django 默认只在每个 App 的static子目录里找静态文件我把文件放在项目根目录的static文件夹里它自然找不到。STATIC_URL /static/ STATICFILES_DIRS [ BASE_DIR / static, ]第二开发服务器没有启动静态文件服务。DEBUGTrue 时 Django 会自动处理静态文件但如果你用的是django.contrib.staticfiles且DEBUGFalse静态文件就要靠python manage.py collectstatic收集到STATIC_ROOT目录再用 Nginx 之类的服务器去服务。新手最容易在部署阶段踩到这个问题。第三模板标签写错。建议用 Django 模板标签而不是硬编码路径写成{% load static %}然后img src{% static img/logo.png %}。这样做的好处是路径会根据STATIC_URL动态拼接不用手动改路径。7.2 ECharts 图表的常见渲染问题图表不显示、显示空白是可视化开发中遇到最多的问题。我把典型情况总结成了一张排查表现象常见原因解决办法页面空白控制台报容器宽高0存放图表的 div 没有设置高度给 div 设置固定高度如height: 400px图表出现但无数据Ajax 接口返回的 JSON 结构不匹配在setOption前用console.log检查接口返回数据更新时新旧数据叠加setOption没有传第二个参数 true改成chart.setOption(option, true)中国地图无法显示ECharts 5 没有内置地图数据引入 GeoJSON并用echarts.registerMap(china, geoJson)折线图 x 轴标签重叠时间点过多且未设置间隔设置xAxis.axisLabel.interval或旋转角度还有一个很隐蔽的问题是多次初始化同一个 DOM 容器。如果页面里initCharts()被调用了两次浏览器会在同一个 div 上初始化两个 ECharts 实例显示异常。解决方法是维护一个全局的charts对象初始化之前先echarts.getInstanceByDom(container)如果已经存在就dispose()掉再重新初始化。7.3 数据查询与删除的坑Django 里执行查询和删除对象如果只是写增删改查确实很简单。但实际项目中我遇到两个典型问题。第一个是级联删除误删数据。上面模型里我把ObservationElement的on_delete设成了CASCADE。这本身是合理的但问题出在我的删除逻辑。我在清理某时间段数据时写的代码是这样的ObservationElement.objects.filter( observation__stationstation, observation__obs_time__range[start, end] ).delete()这条语句执行时删的是明细表的记录但主表Observation还在导致主表有空壳记录图表上会出现大量空数据。后来我改成从主表删除Observation.objects.filter( stationstation, obs_time__range[start, end] ).delete()因为外键的级联设置主表记录删除后关联的明细记录自动删除。这里提醒大家在级联删除的场景下想清楚是从“主表”删还是从“子表”删别搞反了。第二个是时间范围查询的时区问题。如果数据库存储的是 UTC 时间而你用本地时间字符串直接过滤结果会多8小时或者少8小时。我在所有查询里都统一用make_aware处理用户传入的时间确保查询条件也是带时区的再传给 ORM。如果用户从界面选了“今天”后端要转换成“今天00:00到明天00:00”的 UTC 时间这样才能保证图表展示的数据完整。7.4 WebSocket 连接稳定性和部署经验实时推送用起来很爽但部署时问题不少。我遇到过 WebSocket 连接频繁掉线的情况排查了很久最后发现是运行服务器的进程数太多多个进程之间没有共享 channel layer。简单的runserver单进程没这个问题但生产环境用 Daphne 起多个 worker 时必须配置 Redis 作为 channel layer 的后端否则 WebSocket 消息只能在当前进程内传递其他进程的客户端收不到推送。另一个常见问题是反向代理配置。我用 Nginx 部署时如果不配置 Upgrade 和 Connection 头WebSocket 握手就会失败。需要在 Nginx 的 location 里加上这几行location /ws/ { proxy_pass http://django_app; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; }还有一点经验是实时推送的数据要控制频率。观测站数据如果五分钟一条直接推没问题但如果是秒级数据前台会不断触发接口请求页面卡死是迟早的事。我的做法是前端做一次节流收到多条推送消息后合并成一次接口请求并取消上一次未完成的请求保证页面上最多同时有一个数据请求在跑。写到最后想说的这个平台做下来我最深的体会是可视化项目真正的难点往往不在图表本身而在数据质量和前后端联调。ECharts 给了一个很低的起点半小时就能画出一个折线图Django 也给了快速搭建后端的能力一天就能把接口写完。但把海量的海洋气象数据准确、流畅、实时地展示出来需要你在数据模型设计、接口性能、前端渲染细节上投入大量精力。我踩过的坑很多最想分享的不是某个具体语法而是一个习惯每个图表旁边的接口请求都用浏览器开发者工具看一下返回的 JSON 是否正常而不是直接去看图表效果。数据不对图表一定不对但图表不对原因不一定在图表。这个习惯帮我省下了太多排查时间。如果你们也在做类似的数据可视化项目我建议按这个顺序来先梳理清楚数据和业务需求再设计好数据库表然后写接口、画图表最后再做实时推送。顺序不要反。数据模型没理清就急着画图后面返工的痛苦会加倍。希望这篇文章能给你一点实在的参考少走几步弯路。
