简介本资源是一套基于 Django 的汽车数据分析大屏可视化系统项目源码面向具备 Python 与前端基础、希望练习前后端分离开发与数据可视化的开发者。项目采用 Vue 3 搭建界面结合 Echart、DataV 实现折线图、柱状图、饼图等动态刷新渲染后端由 Django 处理业务逻辑与数据存储可用于汽车市场动态、车辆性能等信息的直观展示与分析。压缩包共约 2000 个文件以 1436 个 md 文档、452 个 js 脚本、73 个 json 配置、22 个 py 后端代码及少量 xml、html 等为主整体约 73.95MB。前端目录划分清晰包含 main.js 入口、utils 工具与 mixins、views 主结构与区域组件、assets 静态资源与样式文件、components/echart 图表组件以及适配屏幕尺寸的全局封装代码便于按模块阅读与二次修改。目前已有 96 人学习适合作为课程设计、毕业设计或可视化练手项目的参考方案。1. 从一堆 Excel 到能上墙的汽车数据大屏这套 Django 项目到底能干什么手里攥着几万条汽车销量、投诉、口碑数据领导要你三天内搞出一个能挂在展厅大屏上实时滚动的可视化系统这种需求我接过不止一次。多数人第一反应是上 ECharts 写个静态页但数据一更新就得重新导出、重新部署维护成本高得离谱。这套基于 Django 的汽车数据分析大屏可视化系统解决的正是「数据入库、后端聚合、前端大屏渲染」这条完整链路——它不是一张截图而是一个能跑起来、能换数据源、能二次开发的 Web 工程。适合谁会一点 Python、想拿一个真实业务场景练 Django 全栈的开发者或者手里有汽车行业数据、需要快速搭一套内部看板的从业者。你不需要从零设计表结构也不用纠结大屏适配项目里已经把车型、销量、区域、时间维度这些常见字段的聚合逻辑铺好了你改改数据源就能用。2. Django 数据建模与聚合查询把汽车销量表拆成能喂给大屏的结构2.1 为什么大屏项目的第一道坎是表结构而不是前端很多人拿到项目先去看 HTML 和 CSS结果改了半天样式发现数据根本对不上。大屏的本质是「聚合结果的可视化」后端吐出来的必须已经是按维度算好的指标而不是原始明细。汽车数据常见的维度有时间年/月/季度、地区省/市、车型轿车/SUV/MPV、动力类型燃油/纯电/混动、品牌。如果把这些全塞进一张宽表查询会越来越慢而且前端每换一个图表就得改一次 SQL。常见做法是拆成事实表加维度表。事实表存销量、投诉量、口碑评分这类可累加或可平均的度量值维度表存车型、地区、时间。Django 的 ORM 虽然不如手写 SQL 灵活但配合annotate、values、aggregate做分组聚合完全够用而且迁移方便。我一般会先建三个核心模型CarModel车型维度、Region地区维度、SalesRecord销量事实。下面这段代码是模型定义和一条典型的按月聚合查询你可以直接抄进models.py和视图里。# models.py from django.db import models class CarModel(models.Model): name models.CharField(max_length100, verbose_name车型名称) brand models.CharField(max_length50, verbose_name品牌) category models.CharField(max_length20, verbose_name类别) # 轿车/SUV/MPV power_type models.CharField(max_length20, verbose_name动力类型) class Meta: db_table car_model class Region(models.Model): province models.CharField(max_length50) city models.CharField(max_length50) class Meta: db_table region class SalesRecord(models.Model): car models.ForeignKey(CarModel, on_deletemodels.CASCADE) region models.ForeignKey(Region, on_deletemodels.CASCADE) sale_date models.DateField(verbose_name销售日期) volume models.IntegerField(verbose_name销量) complaint_count models.IntegerField(default0, verbose_name投诉量) class Meta: db_table sales_record indexes [ models.Index(fields[sale_date]), models.Index(fields[car, region]), ]# views.py 片段按月聚合销量供大屏折线图使用 from django.db.models.functions import TruncMonth from django.db.models import Sum from .models import SalesRecord def monthly_sales(request): data ( SalesRecord.objects .annotate(monthTruncMonth(sale_date)) .values(month) .annotate(totalSum(volume)) .order_by(month) ) # data 形如 [{month: date(2024,1,1), total: 15230}, ...] return JsonResponse(list(data), safeFalse)逻辑说明annotate(monthTruncMonth(...))把日期截断到月values(month)指定分组字段再annotate(totalSum(volume))做聚合。参数上TruncMonth依赖数据库的日期函数SQLite 和 MySQL 都支持但如果你用的是 MySQL注意sale_date字段类型要是DATE而不是DATETIME否则截断结果可能带时分秒导致分组错乱。索引那块别省sale_date和carregion的联合索引在数据量过十万后就是救命稻草我见过没加索引的查询从 200ms 飙到 4s。2.2 用 Django 执行查询-删除对象时大屏缓存怎么不翻车热词里有个「django执行查询-删除对象」这在大屏项目里是个真实痛点数据源每天凌晨全量替换你得先删旧记录再批量插入。如果直接SalesRecord.objects.all().delete()在数据量大时会把表锁住大屏前端轮询接口直接超时页面卡成白屏。血泪经验是别用 ORM 的delete()逐条删改用truncate或者分批删除。# 分批删除避免长事务锁表 from django.db import transaction from .models import SalesRecord def clear_old_data(batch_size5000): while True: ids list( SalesRecord.objects.values_list(id, flatTrue)[:batch_size] ) if not ids: break with transaction.atomic(): SalesRecord.objects.filter(id__inids).delete()参数说明batch_size控制每批删除量我一般设 5000太小事务次数多太大单次锁时间长。transaction.atomic()保证每批要么全删要么不删避免删一半中断留下脏数据。另外删除期间大屏接口应该返回上一次的缓存结果而不是直接查库。常见做法是用 Django 的cache框架加一层 Redis删除前先刷新缓存标记前端拿到的是旧数据但至少不报错。这个细节很多教程不讲但生产环境里没它运维电话会被打爆。3. 大屏可视化落地从 Django 模板到 ECharts 的数据对接与自适应3.1 后端接口设计别让大屏等数据大屏和普通网页最大的区别是「常驻展示、自动刷新」。普通页面用户点一下才请求大屏是每隔几十秒自己拉一次。如果每个图表一个接口一屏八个图就是八个请求浏览器并发限制不说后端压力也大。我一般会做一个聚合接口把一屏需要的所有数据一次返回前端拿到后分发给各个图表。# views.py大屏聚合接口 import json from django.core.cache import cache from django.http import JsonResponse from django.db.models import Sum, Avg from django.db.models.functions import TruncMonth from .models import SalesRecord def dashboard_data(request): cache_key dashboard:overview cached cache.get(cache_key) if cached: return JsonResponse(cached) monthly list( SalesRecord.objects .annotate(monthTruncMonth(sale_date)) .values(month) .annotate(totalSum(volume)) .order_by(month) ) by_category list( SalesRecord.objects .values(car__category) .annotate(totalSum(volume)) ) avg_complaint SalesRecord.objects.aggregate(avgAvg(complaint_count)) payload { monthly: [ {month: m[month].strftime(%Y-%m), total: m[total]} for m in monthly ], by_category: by_category, avg_complaint: avg_complaint[avg] or 0, } cache.set(cache_key, payload, timeout300) # 缓存5分钟 return JsonResponse(payload)逻辑说明先查缓存命中直接返回没命中才查库并写缓存。timeout300表示 5 分钟过期大屏刷新频率一般 30 秒到 1 分钟5 分钟缓存足够扛住并发。注意month是date对象JSON 序列化前要转成字符串否则JsonResponse会报错。by_category里用了car__category跨表取值Django 会自动 JOIN但记得CarModel和SalesRecord的外键关系要建对。3.2 ECharts 对接与屏幕自适应1920 和 4K 都要能看前端这块项目里用的是 ECharts这是国内大屏事实上的标准。数据对接就是fetch拿上面那个接口然后setOption。真正容易翻车的是自适应展厅屏幕可能是 1920×1080也可能是 3840×2160甚至拼接屏。如果写死像素换块屏就错位。// dashboard.js async function loadDashboard() { const res await fetch(/api/dashboard/); const data await res.json(); const monthlyChart echarts.init(document.getElementById(monthly)); monthlyChart.setOption({ xAxis: { type: category, data: data.monthly.map(d d.month) }, yAxis: { type: value }, series: [{ type: line, data: data.monthly.map(d d.total) }] }); // 自适应监听窗口变化按比例缩放 window.addEventListener(resize, () { monthlyChart.resize(); }); } loadDashboard(); setInterval(loadDashboard, 60000); // 每分钟刷新参数说明setInterval的 60000 毫秒对应 1 分钟和缓存 300 秒配合实际最多 5 分钟才查一次库。resize()只解决容器尺寸变化如果设计稿是 1920 宽而屏幕是 4K字体和图表元素会显得很小。常见做法是用 CSS 的transform: scale()按屏幕宽度除以 1920 算缩放比或者用rem配合根字体动态计算。我一般会在resize里同时调整根字体大小这样 ECharts 的resize和整体布局一起生效。提示ECharts 实例不要每次刷新都init否则会创建多个实例导致内存泄漏。正确做法是初始化一次后续只setOption更新数据。4. 避坑与排查Django 大屏项目里最容易翻车的五个地方4.1 现象大屏数据不更新接口返回旧值原因缓存没失效。上面用了 5 分钟缓存但数据源凌晨替换后缓存可能还没过期大屏显示的还是昨天的数。解决在数据导入完成后主动cache.delete(dashboard:overview)或者把缓存 key 加上日期后缀比如dashboard:overview:20240501这样每天自然换 key。4.2 现象TruncMonth分组结果出现同月两条记录原因sale_date字段是DateTimeField而不是DateField截断到月后时分秒不同导致分组不合并。解决模型里用DateField或者查询时先annotate一个TruncDate再截月。这个坑我踩过两次数据对不上时先查字段类型。4.3 现象删除旧数据时大屏接口超时原因全表delete()触发长事务数据库锁表。解决改分批删除并且删除期间接口走缓存兜底。另外如果用的是 MySQLdelete后表空间不会立即释放需要OPTIMIZE TABLE但大屏场景一般不需要因为马上会插入新数据。4.4 现象ECharts 图表在 4K 屏上模糊原因Canvas 渲染时没有按设备像素比缩放。解决echarts.init时传入devicePixelRatio: window.devicePixelRatio或者用 SVG 渲染器。另外容器宽高要用 CSS 百分比而不是固定 px否则resize拿到的尺寸不对。4.5 现象Django 创建 app 后忘记注册接口 404原因settings.py的INSTALLED_APPS没加新 app 名。解决每次python manage.py startapp xxx之后立刻去INSTALLED_APPS里补上并且urls.py里include对应路由。这个属于新手高频翻车点但老手偶尔也会因为复制粘贴漏掉。5. 进阶技巧用 Django 管理后台做数据源切换与一键刷新项目跑起来之后你不可能每次都去命令行导数据。Django 自带 admin 后台稍微配置一下就能变成数据管理入口。在admin.py里注册模型运营人员就能直接上传 CSV 或者手动改数据。更进一步可以加一个自定义 admin action点一下「刷新大屏缓存」省得去服务器执行命令。# admin.py from django.contrib import admin from django.core.cache import cache from .models import CarModel, Region, SalesRecord admin.register(SalesRecord) class SalesRecordAdmin(admin.ModelAdmin): list_display (car, region, sale_date, volume, complaint_count) list_filter (sale_date, car__category) actions [refresh_dashboard_cache] admin.action(description刷新大屏缓存) def refresh_dashboard_cache(self, request, queryset): cache.delete(dashboard:overview) self.message_user(request, 大屏缓存已刷新)逻辑说明actions列表里加方法名方法用admin.action装饰并写描述后台就会出现一个下拉操作。cache.delete删掉聚合接口的缓存 key下次大屏请求就会重新查库。参数上list_filter支持跨表字段car__category方便按车型类别筛选。这个技巧把「数据更新」和「大屏刷新」串成了一条运维闭环不用开发介入。验证方法也很直接改一条销量记录点刷新缓存等大屏下一个刷新周期最多 1 分钟看数字有没有变。如果没变先确认缓存 key 是否一致再确认大屏的setInterval是否在跑。我习惯在接口里加一个X-Cache-Hit响应头方便用浏览器开发者工具看这次请求是命中缓存还是查了库。从那以后我每次部署大屏项目都会先把缓存刷新按钮配好再检查一遍TruncMonth的字段类型这两步走完基本不会出玄学问题。希望帮到你。本文还有配套的精品资源点击获取