每年到毕业季总有人为选题纠结到头秃。今天聊的这个项目——城市居民出行模式可视化系统属于典型的一套系统讲完整个技术栈的毕设题目后端用Django提供数据接口前端用ECharts绘制可视化大屏中间再用机器学习模型对未来出行需求做预测最后还接入了deepseek大模型做自然语言问答把大数据、人工智能、深度学习这些关键词全部覆盖到位。这个系统解决什么问题呢说白了就是让城市出行数据从一张张枯燥的表格变成能直观看出规律、能预测未来趋势、还能让非技术人员通过对话直接提问的智能平台。比如高峰时段哪些路段最堵、什么天气下骑行需求会大涨、下个周末某个区域的出行量预计是多少这些问题在系统里都能得到可视化答案。如果你正在准备毕业设计或者想做一个能写进简历的完整项目这篇内容基本可以照着做。我会把环境搭建、数据处理、模型训练、可视化落地、deepseek接入和常见坑位全部过一遍内容比较多建议收藏后慢慢看。1. 先搞清楚系统要做什么需求拆解与技术选型1.1 一个可视化系统解决的不只是画图问题很多人做这类题目的时候容易把它理解成画几张图表。实际做下来你会发现真正的重点在于三个问题数据从哪来、数据怎么变成规律、规律怎么让普通用户一眼看懂。城市居民的出行数据具备典型的大数据特征量大每天成千上万条记录、维度多时间、空间、出行方式、天气、人群属性、实时性要求高早晚高峰的变化几十分钟就能反映出来。如果只用Excel处理最多拉个透视表没法做深层分析如果只做后端统计接口又缺少直观的展示效果。所以这个系统最终定位为一个完整的数据分析闭环数据采集与清洗、指标统计、趋势预测、可视化展示、自然语言交互。这套定位决定了项目不能只堆技术还要有清晰的数据分析逻辑。比如潮汐现象早上大量人流从郊区涌入市中心晚上反向流动是城市交通里很典型的规律通过按时段聚合出发地、目的地再配一张动态的流向图用户立刻就能看出问题。这就是可视化系统相比表格分析的核心价值。1.2 为什么要选DjangoECharts机器学习这条技术路线选技术栈的时候我直接把Spring Boot排除了虽然Java生态也成熟但对Python数据分析生态的支持要绕很多弯。选Django的原因很实在自带ORM和Admin后台原生模板也能撑起简单的管理页面最重要的是Python环境下做机器学习模型非常顺滑训练好的模型可以直接用joblib或pickle保存然后在Django视图里调用整条链路不用切换语言。ECharts这边没什么悬念纯前端开源图表库里面它是最适合做数据大屏的。图形种类全地图、折线、饼图、散点、热力图、词云全都有默认动画效果也漂亮配置项用起来很顺手。相比纯手写SVG或者Canvas开发效率能提升一大截。机器学习部分我用的是scikit-learn加XGBoost这套经典组合来做回归预测主要是预测未来某个时段某个区域的出行需求。深度学习的部分我额外用PyTorch搭了一个简单的LSTM模型做对比实验这样论文里可以写传统机器学习模型与深度学习模型的预测效果对比深度学习和人工智能的关键词也算有了实际落点。1.3 功能模块拆解从数据到图表再到智能问答整个系统的功能模块我是按数据链路拆的这样每个模块的输入输出都很清晰数据采集与清洗模块负责导入原始出行记录处理缺失值、异常值统一时间和地理字段格式。指标统计模块基于Django ORM做聚合查询统计出行总量、时段分布、方式占比、热门区域TOP10等指标。预测模块训练机器学习模型对指定日期、指定区域、指定时段的出行需求进行预测并给出置信区间。可视化大屏模块通过ECharts渲染各类图表配一个整体大屏页面所有指标一目了然。智能问答模块接入deepseek大模型API让用户用自然语言提问比如周五晚上6点从市中心到大学城一般有多少人出行系统通过调用模型接口返回智能回答。模块之间通过标准JSON接口关联前端只负责请求数据和渲染图表后端负责计算和模型推理天然解耦后续扩展也方便。2. 环境准备与数据基础搭建Django工程并完成出行数据建模2.1 开发环境选型与虚拟环境搭建我是在Windows 10上开发的生产环境最后放到了Linux服务器整条链路都踩过一遍这里直接给出可用的方案。Python建议用3.9以上版本Django用3.2或4.x都行数据库选MySQL 5.7以上如果不方便装MySQL直接用SQLite也能跑通但大数据量下建议还是MySQL。先创建虚拟环境再安装依赖包这是老生常谈但很重要的一步不然包版本冲突会让人崩溃python -m venv venv venv\Scripts\activate # Windows # source venv/bin/activate # Linux/Mac pip install django4.2 mysqlclient djangorestframework pandas numpy scikit-learn xgboost joblib openpyxl pip install requests # 后面接deepseek API要用这里有个小提醒mysqlclient在Windows上安装经常失败如果报错可以直接装mysql-connector-python或者改用pymysql并在Django的__init__.py里加一行pymysql.install_as_MySQLdb()实测都能解决。虚拟环境里的Python版本也要确认好我之前吃过系统默认Python和venv版本不一致的亏装包半天才发现装到了全局环境里。2.2 出行数据集的字段设计与预处理这种项目一般拿不到真实的城市级出行数据涉及隐私所以我是自己构造了一套模拟数据再按真实数据的特征做了噪声处理保证模型训练时有意义。字段设计直接决定了后面能做哪些分析我最后留了这些核心字段字段名类型说明idint主键user_idvarchar用户标识start_timedatetime出发时间start_lng / start_latfloat出发地经纬度end_lng / end_latfloat目的地经纬度start_regionvarchar出发区域如市中心end_regionvarchar到达区域travel_modevarchar出行方式地铁/公交/网约车/骑行/步行durationint出行耗时分钟distancefloat出行距离公里weathervarchar天气晴/雨/雪/阴is_holidayint是否节假日0/1预处理阶段最重要的几件事把start_time拆分出hour、weekday、is_peak字段方便后续聚合处理经纬度异常值超出城市范围的数据直接剔除travel_mode统一成固定枚举weather里如果存在小雨大雨这类描述要归一化成雨。这些操作用pandas做很快几十行代码就能搞定清理完之后的数据再批量导入MySQL。2.3 Django模型设计与数据入库Django的MTV模式在这里体现得很清楚Model负责定义表和业务数据Template负责页面展示View负责业务逻辑。很多人把MTV和MVC搞混其实MTV就是MVC的变体Model对应ModelView对应ControllerTemplate对应View理解了这个对应关系后面写代码就不会绕。我在Django里建了一个traffic的app模型大概是这样的# traffic/models.py from django.db import models class TravelRecord(models.Model): user_id models.CharField(max_length32, db_indexTrue) start_time models.DateTimeField(db_indexTrue) start_lng models.FloatField() start_lat models.FloatField() start_region models.CharField(max_length64) end_region models.CharField(max_length64) travel_mode models.CharField(max_length16) duration models.IntegerField() distance models.FloatField() weather models.CharField(max_length16) is_holiday models.IntegerField(default0) class Meta: db_table travel_record indexes [ models.Index(fields[start_time], nameidx_start_time), ]关键点start_time和user_id要加索引因为后面所有聚合查询都绕不开时间范围和用户维度没有索引的话几十万条数据查询就会明显变慢。数据入库我用的是Django的ORM批量创建TravelRecord.objects.bulk_create(records)几万条数据秒入比自己写INSERT语句快得多也不会触发MySQL的packet过大问题。3. 后端核心实现API接口、预测模型与deepseek智能问答3.1 路由与视图设计一套清晰的后端API前端大屏需要的不是一个页面加载时把所有数据都返回而是多个独立接口各自负责一块图表。我设计的接口大致是这样接口路径方法返回内容/api/statistics/overviewGET总出行量、活跃用户数、平均耗时、日均出行量等核心指标/api/statistics/trendGET按小时/按天的出行量变化序列/api/statistics/mode_ratioGET各出行方式占比/api/statistics/hot_regionGET热门出发地/目的地TOP10/api/statistics/flowGET区域之间的出行流向数据/api/predict/demandGET给定日期、区域、时段的出行需求预测/api/chatPOST接收用户问题返回deepseek回答视图层直接用Django REST Framework写序列化器可以省掉很多手写JSON的麻烦。一个典型的趋势接口核心逻辑就是按小时聚合# traffic/views.py from django.db.models import Count from django.http import JsonResponse from .models import TravelRecord def trend_api(request): date request.GET.get(date) qs TravelRecord.objects.filter(start_time__datedate) \ .extra(select{hour: HOUR(start_time)}) \ .values(hour) \ .annotate(cntCount(id)) \ .order_by(hour) data [{hour: item[hour], count: item[cnt]} for item in qs] return JsonResponse({code: 0, data: data})这个接口返回的是标准的JSON数组前端的ECharts折线图拿到之后直接塞进series就行。有一个坑是某小时没有数据时.values(hour)聚合不会返回0会导致折线图缺口。解决办法是在Python侧把小时列表补全不存在的补0。另外JsonResponse建议加上json_dumps_params{ensure_ascii: False}不然返回的中文在部分前端解析时会出现乱码。3.2 出行预测模型特征工程与模型训练详解预测模块是整个项目含金量最高的部分我选的目标是预测未来指定小时、指定区域的出行需求量。这个任务本质是一个回归问题核心工作量在特征工程不在模型。我构造的特征主要有几类时间特征hour、weekday、month、是否周末、是否节假日、空间特征区域编码、外部环境特征weather、温度、风速、历史统计特征过去7天同一时段出行量的均值、最大值。其中历史统计特征对预测效果提升最明显因为城市出行有很强的周期性比如工作日早高峰8点到9点一定是出行量峰值这个规律模型自己学不如直接作为特征喂给它。模型训练我用了一个管道# ml/train_demand.py import pandas as pd import xgboost as xgb from sklearn.model_selection import train_test_split from sklearn.metrics import mean_absolute_error, r2_score import joblib df pd.read_csv(feature_data.csv) feature_cols [hour, weekday, month, is_holiday, is_peak, weather_encoding, region_encoding, last7_mean, last7_max] X df[feature_cols] y df[demand] X_train, X_test, y_train, y_test train_test_split(X, y, test_size0.2, random_state42) model xgb.XGBRegressor(n_estimators500, max_depth6, learning_rate0.05, subsample0.8) model.fit(X_train, y_train) y_pred model.predict(X_test) print(MAE:, mean_absolute_error(y_test, y_pred)) print(R2:, r2_score(y_test, y_pred)) joblib.dump(model, demand_model.pkl)训练结果我这边MAE大概在12左右意味着预测某一小时出行量和真实值平均偏差12人次对大流量场景来说完全可以接受。XGBoost的优势是训练快、对表格数据效果好、特征重要性可以直接分析缺点是超参数多需要调。实测下来n_estimators和learning_rate对结果影响最大我建议先用默认参数跑一遍再慢慢增大树的数量不要一上来就猛调。如果论文里想增加深度学习的角度可以用PyTorch搭LSTM把时间序列按过去7天24小时切成序列样本预测未来24小时的需求。但LSTM对数据量要求高我模拟数据只有几万条训练效果反而不如XGBoost这个对比结果也正好写进论文深度学习在小样本时序预测中不一定优于传统机器学习。Django里加载模型很简单import joblib model joblib.load(ml/demand_model.pkl) def predict_demand_api(request): hour int(request.GET.get(hour)) ... features build_features(...) pred model.predict([features])[0] return JsonResponse({code: 0, predict: round(float(pred), 2)})注意joblib加载模型时模型的Python环境和训练时保持一致不然会出现pickle版本不兼容的报错。模型文件的路径尽量用相对项目根目录的路径避免部署后路径失效。3.3 接入deepseek让系统具备自然语言交互能力deepseek这个模块是我的创新亮点也是答辩时最好讲的一部分。它让系统从只能看图表升级成能对话问数据。整个交互逻辑是这样的用户在输入框里提问后端收到问题后先从文本里提取出与数据分析相关的关键词比如时间、区域然后组合成提示词发送给deepseek的API拿到返回结果后再展示在前端对话框里。调用deepseek API之前需要先去开放平台申请一个API Key然后使用HTTP请求调用接口Python这边用requests就能实现# chat/views.py import requests import json DEEPSEEK_API_URL 你的API端点 DEEPSEEK_API_KEY 你的API Key def chat_api(request): if request.method POST: user_question json.loads(request.body).get(question, ) headers { Authorization: fBearer {DEEPSEEK_API_KEY}, Content-Type: application/json } payload { model: deepseek-chat, messages: [ {role: system, content: 你是一个城市交通数据分析助手请根据已知的交通数据规律回答用户问题。}, {role: user, content: user_question} ], temperature: 0.7 } resp requests.post(DEEPSEEK_API_URL, headersheaders, datajson.dumps(payload), timeout30) result resp.json() answer result[choices][0][message][content] return JsonResponse({code: 0, answer: answer})这里有几个坑必须注意第一API Key绝对不能写死在代码里更不要提交到GitHub上应该用环境变量或者配置文件管理第二接口调用要设置超时时间不然deepseek服务响应慢会导致前端一直转圈第三生产环境建议用Django的StreamingHttpResponse做流式返回这样大模型生成文字时可以边生成边显示用户体感好很多。StreamingHttpResponse相比普通JsonResponse核心区别在于允许持续输出内容块并配合content_type和Content-Disposition参数控制返回格式和文件名。我在开发时用了一个小技巧在系统提示词里把系统统计出的实时指标比如目前系统记录到工作日日均出行量约12000人次一并发给deepseek它回答时就能结合真实数据说话而不是空谈。这个做法答辩的时候特别加分因为评委一眼能看出你不只是调了个接口而是真正做了数据联动。4. ECharts可视化大屏开发从指标定义到图表落地4.1 大屏布局与可视化指标设计可视化大屏是整个系统门面设计好坏直接影响答辩第一印象。我的布局是典型的指挥中心风格顶部是系统标题中间主体区域放中国地图和区域流向左侧放核心指标卡片和出行方式饼图右侧放出行量趋势折线图和热门区域排行榜。大屏整体用深色背景图表用亮色系增加科技感。指标设计上要克制不要所有数据都往上堆。我最终保留了6类核心信息关键指标卡总量、峰值时段、平均耗时、活跃用户数、出行量时间趋势、出行方式占比、热门区域TOP10、区域流向、智能问答入口。每一块都能解释清楚为什么要看这个指标比如出行方式占比可以用来评估公共交通资源分配是否合理热门区域TOP10可以用来做商圈人流预警。前端我是用原生HTMLCSSJavaScript结合ECharts做的没用Vue或React原因很简单大屏页面逻辑不复杂原生技术更直观答辩时也更容易讲清楚。如果要用Vue3注意pxtorem适配问题rem对canvas绘制的ECharts图表没有效需要单独处理字体缩放这个我后面会提到。4.2 ECharts图表实战中国地图、折线图、饼图与柱状图的实现这一节是可视化部分的重头戏。先说中国地图ECharts本身不带地图GeoJSON数据需要手动注册。最简单的方式是下载一个China.js文件引入后通过echarts.registerMap(china, chinaJson)注册。然后配置series的type为map就行// 热门城市出行量地图 var mapChart echarts.init(document.getElementById(mapChart)); fetch(/api/statistics/hot_region) .then(res res.json()) .then(data { mapChart.setOption({ tooltip: {}, visualMap: { min: 0, max: data.maxValue, left: left, text: [高, 低], realtime: false }, series: [{ name: 出行量, type: map, map: china, roam: true, label: { show: false }, data: data.regionList }] }); });地图这块最容易踩的坑是GeoJSON加载失败导致白屏我用的是项目中内置的china.js文件本地路径避免CDN在答辩现场请求不到。另外如果只展示一个城市的内部出行记得把map换成对应城市级的GeoJSON并配合center和zoom把视角定位到目标城市。折线图做出行量趋势特别合适把后端返回的hour和count直接映射到坐标轴就行。这里有一个体验优化点数据多的时候x轴刻度会挤成一团建议在xAxis里设置axisLabel: { interval: auto, rotate: 30 }让文字倾斜显示并且tooltip里的内容用formatter做多行显示一行时间一行出行量这样信息更清晰。饼图和柱状图相对简单精力主要花在样式上。饼图的legend默认在右边我改成底部并设置itemWidth和itemHeight保证图例大小统一柱状图在排行榜场景下有一个方便的技巧用yAxis的category类目轴让柱子横向排列排名从上到下展示视觉上比竖向柱状图更舒服。4.3 前后端联调Ajax请求、数据格式约定与异步刷新大屏和普通页面不一样它需要在没有刷新动作的情况下持续更新。我用的是最直接的方案页面加载完成后执行一次initAllCharts()把每个接口的数据请求打包然后在每个图表内更新。定时刷新就挂一个setInterval每60秒重新请求一次实时性较强的接口比如出行总量和趋势折线图。接口数据格式我在后端统一成{code: 0, msg: ok, data: ...}前端判断code 0才处理data这样出错时能快速定位是后端异常还是渲染异常。还有一个兼容性细节Django的JsonResponse默认对中文不转义但某些前端环境解析会有兼容问题可以在JsonResponse里加json_dumps_params{ensure_ascii: False}保证前端拿到的中文是正常字符。如果上线部署前端build后的静态文件我建议统一交给Django管理配置好STATIC_ROOT和STATICFILES_DIRS执行collectstatic收集所有静态文件这样一台服务器就能搞定全部服务不需要额外部署Node环境。5. 常见问题与排查实战5.1 我踩过的坑与解决记录先说几个让我印象最深的坑每一个都花了我不少时间。第一个是跨域问题。前端页面如果和后端不在同一个端口下开发比如前端用live-server跑在5500后端Django跑在8000Ajax请求必然跨域。排查方法很简单打开浏览器F12看Network如果请求显示CORS错误就在Django安装django-cors-headers配置CORS_ALLOWED_ORIGINS列表把前端地址加进去。第二个是ECharts地图白屏。我之前图省事直接从CDN引入china.js结果答辩前一天网络抽风地图一直加载不出来。后来改成把china.js下载到本地静态目录用script src{% static js/china.js %}/script引入彻底告别网络依赖。第三个是数据库聚合查询超时。数据量到了几十万条以后Django的ORM做多表联查会明显变慢最直接的办法是加索引其次是把复杂的聚合先算好并缓存到Redis里定时更新而不是每次请求都去跑全量查询。5.2 性能优化与部署建议大屏类系统对首屏速度和数据响应速度都比较敏感。我在性能优化上做了三件事第一把不需要实时更新的图表数据比如地图GeoJSON、出行方式占比在后端加了一层简单的缓存用Django的cache框架存5分钟第二把前端的大体积图表库拆开按需引入ECharts使用echarts/core的方式按需注册组件首屏体积能省掉约三分之一第三批量查询用values()加annotate()而不是把所有记录load到内存再统计。部署方面我最终用的方案是Linux服务器 Nginx WaitressWindows上的等待服务器也可以用。Django自带的runserver只适合开发不能直接暴露在公网。生产环境把项目交给Gunicorn或Waitress跑再用Nginx做反向代理和静态文件服务整个架构很成熟。如果数据量进一步增长可以考虑引入大数据集群方案做离线计算但毕设阶段Django加MySQL完全足够别为了追求架构复杂度把自己绕进去。5.3 这个项目还能怎么扩展这个系统做完以后有很多明确可扩展的方向。第一是接入真实数据源比如城市公开的交通刷卡数据或者公交定位数据把模拟数据替换成真数据项目的真实性会大幅提升。第二是增加更多机器学习任务除了出行需求预测还可以做出行方式推荐分类问题、异常出行检测异常检测问题、拥堵等级识别多分类问题每个都能单独写成一篇论文章节。第三是增加实时数据接入用WebSocket推送实时轨迹大屏上就能看到车辆移动的动画效果视觉冲击力很强。如果你打算把这个项目作为求职作品我建议再补充一份完整的README文档把项目结构、接口文档、模型训练流程、部署步骤都写清楚面试官看重的不只是代码跑起来更是你的工程化能力。做这个项目的过程中我最大的体会是技术选型不重要重要的是能不能把整条链路讲通。Django、ECharts、机器学习、deepseek这些技术单独拿出来都不难难的是把数据、模型、可视化、交互串成一个闭环。遇到问题时别急着换技术栈先静下心来排查大多数问题都出在数据格式、路径配置、版本兼容这些细节上。最后建议你在答辩前一定要在干净的电脑上重新跑一遍部署流程这一步能帮你避开至少一半现场翻车的风险。