简介一套基于 Python、Django 与 MySQL 的智慧交通公交系统项目源码面向正在学习 Web 开发、数据库设计或智慧城市相关课题的高校学生与开发者可服务于课程设计、毕业设计或技术进阶场景。项目以后端框架 Django 构建业务逻辑结合 MySQL 存储线路、车辆、站点、时刻表等数据覆盖用户管理、线路管理、车辆管理、地图展示与数据分析等模块形成完整的公交信息管理闭环。资源包共 1510 个文件包含 Python 源码、SQL 数据库脚本、HTML/CSS/JavaScript 前端页面、设计文档与图片素材等整体约 114.15MB目录结构清晰便于部署运行或按需查阅。目前已有 2105 人学习/下载适合入门至进阶的 Python Web 开发者参考。通过这套资料可拿到可运行的 Django 项目、数据库模型CDM/PDM、需求文档及静态资源能直观理解 MTV 架构、ORM 操作与 MySQL 数据建模方法同时借鉴智慧交通场景下的业务分层与接口设计快速上手同类系统开发。1. 智慧交通公交系统这套 Django 项目源码到底能不能落地如果说课程设计里最容易翻车的选题智慧交通公交系统一定排前三。它听起来只是做几个页面实际上一旦拆开就涉及 Django 路由、MySQL 事务、坐标字段存储、车辆调度状态流转甚至还要给统计报表留接口。这份 pythondjangomysql 打包资源我完整拆过一遍后台管理、线路站点维护、车辆排班、基础可视化报表都有适合毕设给导师演示也适合想快速搭一套公交信息管理后台的在职开发者。能用但坑不少——数据库字段设计、时区处理、静态文件迁移每一项都能让你卡到怀疑人生。2. 先拆表设计MySQL 里这 8 个字段决定了系统下限2.1 Django 项目分层views/models/urls 的边界别过早优化拿到这套资源后第一件事不要直接跑python manage.py runserver先把项目目录结构看清楚。典型的 Django 结构是一个project加若干app比如bus_app管车辆和线路user_app管登录权限report_app管报表。这种拆法不是花架子是为了让后面加功能时不至于把所有业务塞进一个models.py里。我见过不少二次开发的人把调度逻辑写在视图函数里结果后来要加定时任务找半天不知道钩子挂在哪。这套系统给我的感觉是它把业务逻辑放在views.py把数据校验放在forms.py把数据库操作放在views.py里直接调用objects.filter()。没有用serializer也没上DRF说明前端走的是模板渲染加少量 Ajax。这个选择其实很务实不搞前后端分离部署成本低一台服务器就能跑。对于课设和中小型项目这比硬上 Vue 分开部署更省心。2.2 核心表结构与索引从 line 表到 bus_route 表MySQL 部分的表设计是这套资源里最值得参考也最容易踩坑的地方。基础表有四张line线路表、station站点表、bus车辆表、route路径表。其中route表是线路和站点的关联表用来记录某条线路经过哪些站点、先后顺序是什么这是电车公交系统比较核心的设计。下面这段 Django 模型代码基本还原了这套资源里线路和站点的建模方式# apps/bus/models.py from django.db import models class Line(models.Model): name models.CharField(线路名称, max_length50) code models.CharField(线路编号, max_length20, uniqueTrue) start_station models.CharField(起点站, max_length100) end_station models.CharField(终点站, max_length100) first_bus models.TimeField(首班时间) last_bus models.TimeField(末班时间) price models.DecimalField(票价, max_digits5, decimal_places2, default1.00) status models.BooleanField(是否运营, defaultTrue) create_time models.DateTimeField(创建时间, auto_now_addTrue) class Meta: db_table line ordering [code] verbose_name 公交线路 def __str__(self): return f{self.code} {self.name}这里两个细节需要注意。第一code字段加了uniqueTrue表示线路编号在系统里唯一。如果导入数据时有两批历史数据编号冲突迁移会失败所以这个字段看着简单实际上决定了能不能批量初始化数据。第二price用的是DecimalField而不是FloatField小数计算避免浮点误差这在做票价统计时很关键。用FloatField后报表小数位出现 0.0000001 的误差就属于典型的自找麻烦。route关联表是这样的class Route(models.Model): line models.ForeignKey(Line, on_deletemodels.CASCADE, verbose_name所属线路) station models.ForeignKey(Station, on_deletemodels.CASCADE, verbose_name站点) seq models.IntegerField(站点序号, default0) distance_from_start models.FloatField(距起点距离(km), default0.0)seq就是站点在线路上的顺序1 表示起点站2 表示第二站以此类推。distance_from_start是给后续计算站间距用的有些报表需要统计线路总长。如果资源里没有这个字段建议自己加因为以后画线路图或做区间价格都离不开它。这里用一张表把这几个核心字段整理出来方便你做二次开发时对字段类型表名关键字段字段类型用途linecodevarchar(20), unique线路唯一标识linefirst_bus / last_bustime首末班时间stationnamevarchar(100)站名routeline_id station_id seqint线路与站点多对多关联busline_id plate_numbervarchar int车辆基础信息Route表属于多对多中的中间表在 Django 里可以用ManyToManyField加through参数建模但直接写 ForeignKey 更直观而且能方便地加seq和距离字段。这套资源用的就是后者比较推荐。3. 核心业务实现从 station 管理到车辆调度状态机3.1 基于 ModelForm 的线路/站点增删改查这套系统的后台管理采用 Django Admin 加自定义页面的混合方式。线路和站点维护走的是模板页面配合ModelForm用/line/add和/line/edit/3这样的路由区分操作。一个比较典型的视图写法如下# apps/bus/views.py from django.shortcuts import render, redirect, get_object_or_404 from django.contrib.auth.decorators import login_required from .models import Line, Route, Station from .forms import LineForm login_required def line_edit(request, line_idNone): if line_id: line get_object_or_404(Line, pkline_id) form LineForm(request.POST or None, instanceline) else: form LineForm(request.POST or None) if request.method POST and form.is_valid(): form.save() return redirect(/line/list/) return render(request, bus/line_form.html, {form: form})这里用login_required做登录态校验避免未登录用户直接改数据。LineForm在forms.py里定义通常是这样# apps/bus/forms.py from django.forms import ModelForm from .models import Line class LineForm(ModelForm): class Meta: model Line fields [name, code, start_station, end_station, first_bus, last_bus, price, status]fields显式列出可编辑字段而不是用__all__是为了防止用户修改create_time或id这类不该动的字段。如果你在二次开发时发现新增字段保存不了第一反应应该去看fields列表里有没有漏掉新字段。新增和编辑走同一个视图是这里最值得模仿的设计只写一个line_edit函数用line_id是不是 None 来区分新增和编辑少写一个视图路由也少写一条。这套资源里站点管理也是同样的套路你改某个字段时就能复用这套逻辑。3.2 车辆调度状态流转手动标记还是定时器车辆状态是一个业务难点。一套公交系统里车辆至少要经历 待发车、运行中、到终点站、回场 这几种状态。这套资源的设计比较朴素直接在bus表上放一个status字段用 0/1/2 表示 待发/运行/回场。前端通过下拉框手动修改状态没有做自动流转。class Bus(models.Model): plate_number models.CharField(车牌号, max_length20, uniqueTrue) line models.ForeignKey(Line, on_deletemodels.SET_NULL, nullTrue, blankTrue) driver_name models.CharField(驾驶员, max_length30) status models.IntegerField(状态, choices[ (0, 待发车), (1, 运行中), (2, 已回场), ], default0) last_longitude models.FloatField(经度, default0.0) last_latitude models.FloatField(纬度, default0.0) update_time models.DateTimeField(位置更新时间, auto_nowTrue)status用IntegerField加choices比字符串存running/idle更省空间也避免手滑写错状态值。不过只做手动选择有一个明显问题司机到站后没人手动点按钮状态就一直是运行中。实际项目里一般会做定时任务模拟发车和到站或者在车载终端上报数据时自动推进状态。如果你拿到压缩包后想改成自动状态机一个低成本的思路是加一个last_status字段再写一个update_bus_status.py脚本配合 Linux 的crontab每分钟跑一次判断update_time距离当前时间超过 15 分钟就强制改成回场。这样至少不让数据一直悬在运行中。车辆定位这块last_longitude和last_latitude直接用 Float 存经纬度查询很简单但要注意经纬度精度问题。做地图展示时Python 高德地图 SDK 对坐标格式也有要求传入的经纬度如果超过 6 位小数显示位置能接受但入库前统一四舍五入到 6 位比较好。这个经验是从一次地图偏移踩坑里总结出来的。4. 报表与查询优化让统计接口不至于拖垮数据库4.1 分页与过滤用 Django paginator 和 queryset 组合系统里有一个报表模块统计各线路日均发车次、日均客流估算值、准点率。这类报表接口最容易出现的问题就是快不起来。一个运营中的公交系统线路几十条站点几百个运行记录每天上万条直接Model.objects.all()再把全部数据传给模板页面会卡到怀疑人生。这份资源里做到了分页用的就是自带的Paginator# apps/report/views.py from django.core.paginator import Paginator from django.shortcuts import render from .models import BusRecord def report_list(request): records BusRecord.objects.filter( line__statusTrue, create_date__range[2024-01-01, 2024-01-31] ).order_by(-create_time) paginator Paginator(records, 20) page_number request.GET.get(page) page_obj paginator.get_page(page_number) return render(request, report/list.html, {page_obj: page_obj})注意filter里用了create_date__range这比在 Python 里做日期比较快得多因为range查询直接生成 SQL 的BETWEEN条件而不是把全部记录拉到内存后逐条比对。order_by(-create_time)是必须的否则不同页数据顺序会漂移翻页时会出现重复记录。Paginator的参数20表示每页 20 条。如果做的后台报表每日数据量不大也可以改成 50 或 100。但如果你是给手机端写接口建议保持 20 条以内移动端渲染列表太长反而体验差。4.2 EXPLAIN 看执行计划索引失效的三个典型翻车点这套系统里最容易出性能问题的查询有三个按线路查车辆列表、按时间范围查运行记录、按站点查经过线路。写查询时什么都对但实际车速很慢。所以你得备份一个数据库后去 MySQL 命令行里跑EXPLAIN看索引到底有没有命中。典型翻车点一LINE表上的status字段用了布尔值然后在WHERE status1时走了全表扫描。布尔字段在 MySQL 里选择性太低加索引也没意义所以查询时这时候可以考虑只查line__code或line__name的组合条件让前缀索引生效。典型翻车点二日期字段用了create_time加上create_date双字段冗余。如果查询时在create_date上做DATE_FORMAT(create_time) 2024-01-01这种写法索引直接失效因为 MySQL 对每一行都执行了函数计算。正确做法是直接传日期对象给range不要在查询里对字段做函数包裹。典型翻车点三route表的line_id外键字段没建索引。Django 的ForeignKey默认会自动建索引但如果 SQL 里手动建了表且没跑migrate的索引同步就会出现外键查询特别慢的问题。这种问题属于黑匣子不到数据量大了很难发现但等到报表响应超过 5 秒再回头查就晚了。建议在 MySQL 里执行下面这条语句验证一下EXPLAIN SELECT * FROM route WHERE line_id 3;看到key列不是空的值才说明索引确实用上了。如果type列显示ALL那就是没走索引需要ALTER TABLE route ADD INDEX idx_line_id (line_id);手工补一个。5. 部署避坑本机跑通到服务器上线最容易踩的 5 个坑5.1 版本匹配python3.8 Django3.2 还是 python3.10 Django4.2我第一次跑这套资源时直接用 Python 3.12 和最新版 Django结果mysqlclient编译阶段直接报错。后来翻安装要求才知道Django 3.2 长期支持版配 Python 3.8 到 3.10 最稳定Django 4.2 配 Python 3.10 以上较稳。项目里如果用的MySQLdb数据库驱动Python 新版本对 C 扩展兼容性差很容易让你白折腾一下午。建议用虚拟环境固定版本python3.10 -m venv venv source venv/bin/activate pip install django3.2.20 mysqlclient2.0.3mysqlclient依赖系统里的libmysqlclient-dev在 Ubuntu 上先执行sudo apt install default-libmysqlclient-dev再装比较稳。跑之前先python manage.py check如果有版本 API 差异会直接给你列出来。别用pip install -r requirements.txt一把梭除非你知道那份依赖列表是哪个年代写的。5.2 静态文件与上传目录Nginx 接管后的权限坑本地开发时runserver能直接加载静态文件一旦换到 Nginx 加 uWSGI 的部署环境静态文件就该交给 Nginx而不是让 Django 硬抗。打开项目里的settings.py重点看这三个配置STATIC_URL /static/ STATIC_ROOT /var/www/bus_system/static/ STATICFILES_DIRS [BASE_DIR / static]STATIC_ROOT是collectstatic收集后存放的目录这个目录必须让 Nginx 有读取权限。我踩过一次部署完页面 HTML 能打开但 CSS、JS 全部 404排查半天发现目录属主是 rootNginx 的www-data用户读不了。解决方式sudo chown -R www-data:www-data /var/www/bus_system/static/上传图片或导入 Excel 时更要注意MEDIA_ROOT目录权限。Django 写文件时用的是运行 Web 服务的用户如果 uWSGI 进程是 root 启动写出来的文件 root 所有后续要删除或覆盖就会权限混乱。规范做法是给 uWSGI 单独建一个低权限用户并确保上传目录归它所有。5.3 常见问题排查从迁移冲突到时区错乱这套资源在全新环境上容易碰到三个高频报错按现象、原因、解决来列报错一执行python manage.py migrate时提示django.db.migrations.exceptions.InconsistentMigrationHistory。原因是本地的migrations目录里留下了旧的历史迁移文件和数据表记录对不上。处理办法是备份数据库然后删除相关 app 的migrations文件重新跑makemigrations和migrate。如果数据重要可以先用python manage.py dumpdata导出再重建数据库。报错二OperationalError: (2002, Cant connect to local MySQL server through socket /var/run/mysqld/mysqld.sock)。原因是 MySQL 没启动或 Django 的settings.py里HOST配成了 localhost 导致 Python 走 socket 文件。解决方式确认service mysql status如果 MySQL 正常就把HOST改成127.0.0.1这样会走 TCP 而不是 socket。报错三后台录入的first_bus时间到了前端显示变成前一天晚上 8 点。这是非常典型的时区问题。在settings.py里要同时设置TIME_ZONE Asia/Shanghai和USE_TZ TrueMySQL 连接参数里还要加OPTIONS: {charset: utf8mb4}。如果你只是改了系统时区而不改TIME_ZONEDjango 会在存入 MySQL 时自动转 UTC读取时再转回本地时间显示就会错乱。这套资源在线路时间维护上就踩过这个坑我后来在处理任何时间字段前都先看一眼settings.py里这两行。6. 进阶接入 Redis 做实时车辆位置缓存降低数据库压力当你把车辆定位数据上报频率提高比如每 10 秒一次几十辆车同时写入bus表的last_longitude和last_latitudeMySQL 的update_time字段会频繁更新高峰期报表查询和位置更新互相锁等待。一个缓解思路是引入 Redis把车辆实时位置放缓存里MySQL 只做低频持久化。缓存模块大致长这样# apps/bus/cache.py import redis pool redis.ConnectionPool(host127.0.0.1, port6379, db0, decode_responsesTrue) client redis.Redis(connection_poolpool) def get_bus_position(plate_number): position client.hget(fbus_pos:{plate_number}, loc) if position: return position # 缓存未命中回源 MySQL bus Bus.objects.get(plate_numberplate_number) save_bus_position(plate_number, bus.last_longitude, bus.last_latitude) return f{bus.last_longitude},{bus.last_latitude} def save_bus_position(plate_number, longitude, latitude): client.hset(fbus_pos:{plate_number}, mapping{ loc: f{longitude},{latitude}, update_time: str(int(time.time())) }) client.expire(fbus_pos:{plate_number}, 60)这里用 Redis 的 hash 结构存位置每个车牌号对应一个 key过期时间 60 秒保证单条位置数据不会长期占用内存。查询车辆的实时位置时先查 Redis没有再去 MySQL 补这种方式能显著降低数据库的写读频率。注意decode_responsesTrue可以让 Redis 返回的字符串不被包裹成 bytes否则前端拼接坐标时会一直报类型错误。这套资源里没有直接集成 Redis所以二次开发时你需要自己启动 Redis 服务并在requirements.txt里加redis依赖。我建议在接入前先做一个开关在settings.py里写一个USE_REDIS True变量这样如果部署环境没有 Redis设置为 False 时系统仍能回落到 MySQL不至于直接崩。从那以后我每次拿到新项目都会强制走一遍这个检查流程先看settings.py时区和静态文件再看模型里时间字段类型最后再决定要不要加中间件——顺序错了后面往往要返工。这套公交系统源码本身骨架不错只要把表结构理解清部署时避开版本和静态文件两座大山剩下就是在业务逻辑上慢慢磨了。希望帮到你。本文还有配套的精品资源点击获取
简介一套基于 Python、Django 与 MySQL 的智慧交通公交系统项目源码面向正在学习 Web 开发、数据库设计或智慧城市相关课题的高校学生与开发者可服务于课程设计、毕业设计或技术进阶场景。项目以后端框架 Django 构建业务逻辑结合 MySQL 存储线路、车辆、站点、时刻表等数据覆盖用户管理、线路管理、车辆管理、地图展示与数据分析等模块形成完整的公交信息管理闭环。资源包共 1510 个文件包含 Python 源码、SQL 数据库脚本、HTML/CSS/JavaScript 前端页面、设计文档与图片素材等整体约 114.15MB目录结构清晰便于部署运行或按需查阅。目前已有 2105 人学习/下载适合入门至进阶的 Python Web 开发者参考。通过这套资料可拿到可运行的 Django 项目、数据库模型CDM/PDM、需求文档及静态资源能直观理解 MTV 架构、ORM 操作与 MySQL 数据建模方法同时借鉴智慧交通场景下的业务分层与接口设计快速上手同类系统开发。1. 智慧交通公交系统这套 Django 项目源码到底能不能落地如果说课程设计里最容易翻车的选题智慧交通公交系统一定排前三。它听起来只是做几个页面实际上一旦拆开就涉及 Django 路由、MySQL 事务、坐标字段存储、车辆调度状态流转甚至还要给统计报表留接口。这份 pythondjangomysql 打包资源我完整拆过一遍后台管理、线路站点维护、车辆排班、基础可视化报表都有适合毕设给导师演示也适合想快速搭一套公交信息管理后台的在职开发者。能用但坑不少——数据库字段设计、时区处理、静态文件迁移每一项都能让你卡到怀疑人生。2. 先拆表设计MySQL 里这 8 个字段决定了系统下限2.1 Django 项目分层views/models/urls 的边界别过早优化拿到这套资源后第一件事不要直接跑python manage.py runserver先把项目目录结构看清楚。典型的 Django 结构是一个project加若干app比如bus_app管车辆和线路user_app管登录权限report_app管报表。这种拆法不是花架子是为了让后面加功能时不至于把所有业务塞进一个models.py里。我见过不少二次开发的人把调度逻辑写在视图函数里结果后来要加定时任务找半天不知道钩子挂在哪。这套系统给我的感觉是它把业务逻辑放在views.py把数据校验放在forms.py把数据库操作放在views.py里直接调用objects.filter()。没有用serializer也没上DRF说明前端走的是模板渲染加少量 Ajax。这个选择其实很务实不搞前后端分离部署成本低一台服务器就能跑。对于课设和中小型项目这比硬上 Vue 分开部署更省心。2.2 核心表结构与索引从 line 表到 bus_route 表MySQL 部分的表设计是这套资源里最值得参考也最容易踩坑的地方。基础表有四张line线路表、station站点表、bus车辆表、route路径表。其中route表是线路和站点的关联表用来记录某条线路经过哪些站点、先后顺序是什么这是电车公交系统比较核心的设计。下面这段 Django 模型代码基本还原了这套资源里线路和站点的建模方式# apps/bus/models.py from django.db import models class Line(models.Model): name models.CharField(线路名称, max_length50) code models.CharField(线路编号, max_length20, uniqueTrue) start_station models.CharField(起点站, max_length100) end_station models.CharField(终点站, max_length100) first_bus models.TimeField(首班时间) last_bus models.TimeField(末班时间) price models.DecimalField(票价, max_digits5, decimal_places2, default1.00) status models.BooleanField(是否运营, defaultTrue) create_time models.DateTimeField(创建时间, auto_now_addTrue) class Meta: db_table line ordering [code] verbose_name 公交线路 def __str__(self): return f{self.code} {self.name}这里两个细节需要注意。第一code字段加了uniqueTrue表示线路编号在系统里唯一。如果导入数据时有两批历史数据编号冲突迁移会失败所以这个字段看着简单实际上决定了能不能批量初始化数据。第二price用的是DecimalField而不是FloatField小数计算避免浮点误差这在做票价统计时很关键。用FloatField后报表小数位出现 0.0000001 的误差就属于典型的自找麻烦。route关联表是这样的class Route(models.Model): line models.ForeignKey(Line, on_deletemodels.CASCADE, verbose_name所属线路) station models.ForeignKey(Station, on_deletemodels.CASCADE, verbose_name站点) seq models.IntegerField(站点序号, default0) distance_from_start models.FloatField(距起点距离(km), default0.0)seq就是站点在线路上的顺序1 表示起点站2 表示第二站以此类推。distance_from_start是给后续计算站间距用的有些报表需要统计线路总长。如果资源里没有这个字段建议自己加因为以后画线路图或做区间价格都离不开它。这里用一张表把这几个核心字段整理出来方便你做二次开发时对字段类型表名关键字段字段类型用途linecodevarchar(20), unique线路唯一标识linefirst_bus / last_bustime首末班时间stationnamevarchar(100)站名routeline_id station_id seqint线路与站点多对多关联busline_id plate_numbervarchar int车辆基础信息Route表属于多对多中的中间表在 Django 里可以用ManyToManyField加through参数建模但直接写 ForeignKey 更直观而且能方便地加seq和距离字段。这套资源用的就是后者比较推荐。3. 核心业务实现从 station 管理到车辆调度状态机3.1 基于 ModelForm 的线路/站点增删改查这套系统的后台管理采用 Django Admin 加自定义页面的混合方式。线路和站点维护走的是模板页面配合ModelForm用/line/add和/line/edit/3这样的路由区分操作。一个比较典型的视图写法如下# apps/bus/views.py from django.shortcuts import render, redirect, get_object_or_404 from django.contrib.auth.decorators import login_required from .models import Line, Route, Station from .forms import LineForm login_required def line_edit(request, line_idNone): if line_id: line get_object_or_404(Line, pkline_id) form LineForm(request.POST or None, instanceline) else: form LineForm(request.POST or None) if request.method POST and form.is_valid(): form.save() return redirect(/line/list/) return render(request, bus/line_form.html, {form: form})这里用login_required做登录态校验避免未登录用户直接改数据。LineForm在forms.py里定义通常是这样# apps/bus/forms.py from django.forms import ModelForm from .models import Line class LineForm(ModelForm): class Meta: model Line fields [name, code, start_station, end_station, first_bus, last_bus, price, status]fields显式列出可编辑字段而不是用__all__是为了防止用户修改create_time或id这类不该动的字段。如果你在二次开发时发现新增字段保存不了第一反应应该去看fields列表里有没有漏掉新字段。新增和编辑走同一个视图是这里最值得模仿的设计只写一个line_edit函数用line_id是不是 None 来区分新增和编辑少写一个视图路由也少写一条。这套资源里站点管理也是同样的套路你改某个字段时就能复用这套逻辑。3.2 车辆调度状态流转手动标记还是定时器车辆状态是一个业务难点。一套公交系统里车辆至少要经历 待发车、运行中、到终点站、回场 这几种状态。这套资源的设计比较朴素直接在bus表上放一个status字段用 0/1/2 表示 待发/运行/回场。前端通过下拉框手动修改状态没有做自动流转。class Bus(models.Model): plate_number models.CharField(车牌号, max_length20, uniqueTrue) line models.ForeignKey(Line, on_deletemodels.SET_NULL, nullTrue, blankTrue) driver_name models.CharField(驾驶员, max_length30) status models.IntegerField(状态, choices[ (0, 待发车), (1, 运行中), (2, 已回场), ], default0) last_longitude models.FloatField(经度, default0.0) last_latitude models.FloatField(纬度, default0.0) update_time models.DateTimeField(位置更新时间, auto_nowTrue)status用IntegerField加choices比字符串存running/idle更省空间也避免手滑写错状态值。不过只做手动选择有一个明显问题司机到站后没人手动点按钮状态就一直是运行中。实际项目里一般会做定时任务模拟发车和到站或者在车载终端上报数据时自动推进状态。如果你拿到压缩包后想改成自动状态机一个低成本的思路是加一个last_status字段再写一个update_bus_status.py脚本配合 Linux 的crontab每分钟跑一次判断update_time距离当前时间超过 15 分钟就强制改成回场。这样至少不让数据一直悬在运行中。车辆定位这块last_longitude和last_latitude直接用 Float 存经纬度查询很简单但要注意经纬度精度问题。做地图展示时Python 高德地图 SDK 对坐标格式也有要求传入的经纬度如果超过 6 位小数显示位置能接受但入库前统一四舍五入到 6 位比较好。这个经验是从一次地图偏移踩坑里总结出来的。4. 报表与查询优化让统计接口不至于拖垮数据库4.1 分页与过滤用 Django paginator 和 queryset 组合系统里有一个报表模块统计各线路日均发车次、日均客流估算值、准点率。这类报表接口最容易出现的问题就是快不起来。一个运营中的公交系统线路几十条站点几百个运行记录每天上万条直接Model.objects.all()再把全部数据传给模板页面会卡到怀疑人生。这份资源里做到了分页用的就是自带的Paginator# apps/report/views.py from django.core.paginator import Paginator from django.shortcuts import render from .models import BusRecord def report_list(request): records BusRecord.objects.filter( line__statusTrue, create_date__range[2024-01-01, 2024-01-31] ).order_by(-create_time) paginator Paginator(records, 20) page_number request.GET.get(page) page_obj paginator.get_page(page_number) return render(request, report/list.html, {page_obj: page_obj})注意filter里用了create_date__range这比在 Python 里做日期比较快得多因为range查询直接生成 SQL 的BETWEEN条件而不是把全部记录拉到内存后逐条比对。order_by(-create_time)是必须的否则不同页数据顺序会漂移翻页时会出现重复记录。Paginator的参数20表示每页 20 条。如果做的后台报表每日数据量不大也可以改成 50 或 100。但如果你是给手机端写接口建议保持 20 条以内移动端渲染列表太长反而体验差。4.2 EXPLAIN 看执行计划索引失效的三个典型翻车点这套系统里最容易出性能问题的查询有三个按线路查车辆列表、按时间范围查运行记录、按站点查经过线路。写查询时什么都对但实际车速很慢。所以你得备份一个数据库后去 MySQL 命令行里跑EXPLAIN看索引到底有没有命中。典型翻车点一LINE表上的status字段用了布尔值然后在WHERE status1时走了全表扫描。布尔字段在 MySQL 里选择性太低加索引也没意义所以查询时这时候可以考虑只查line__code或line__name的组合条件让前缀索引生效。典型翻车点二日期字段用了create_time加上create_date双字段冗余。如果查询时在create_date上做DATE_FORMAT(create_time) 2024-01-01这种写法索引直接失效因为 MySQL 对每一行都执行了函数计算。正确做法是直接传日期对象给range不要在查询里对字段做函数包裹。典型翻车点三route表的line_id外键字段没建索引。Django 的ForeignKey默认会自动建索引但如果 SQL 里手动建了表且没跑migrate的索引同步就会出现外键查询特别慢的问题。这种问题属于黑匣子不到数据量大了很难发现但等到报表响应超过 5 秒再回头查就晚了。建议在 MySQL 里执行下面这条语句验证一下EXPLAIN SELECT * FROM route WHERE line_id 3;看到key列不是空的值才说明索引确实用上了。如果type列显示ALL那就是没走索引需要ALTER TABLE route ADD INDEX idx_line_id (line_id);手工补一个。5. 部署避坑本机跑通到服务器上线最容易踩的 5 个坑5.1 版本匹配python3.8 Django3.2 还是 python3.10 Django4.2我第一次跑这套资源时直接用 Python 3.12 和最新版 Django结果mysqlclient编译阶段直接报错。后来翻安装要求才知道Django 3.2 长期支持版配 Python 3.8 到 3.10 最稳定Django 4.2 配 Python 3.10 以上较稳。项目里如果用的MySQLdb数据库驱动Python 新版本对 C 扩展兼容性差很容易让你白折腾一下午。建议用虚拟环境固定版本python3.10 -m venv venv source venv/bin/activate pip install django3.2.20 mysqlclient2.0.3mysqlclient依赖系统里的libmysqlclient-dev在 Ubuntu 上先执行sudo apt install default-libmysqlclient-dev再装比较稳。跑之前先python manage.py check如果有版本 API 差异会直接给你列出来。别用pip install -r requirements.txt一把梭除非你知道那份依赖列表是哪个年代写的。5.2 静态文件与上传目录Nginx 接管后的权限坑本地开发时runserver能直接加载静态文件一旦换到 Nginx 加 uWSGI 的部署环境静态文件就该交给 Nginx而不是让 Django 硬抗。打开项目里的settings.py重点看这三个配置STATIC_URL /static/ STATIC_ROOT /var/www/bus_system/static/ STATICFILES_DIRS [BASE_DIR / static]STATIC_ROOT是collectstatic收集后存放的目录这个目录必须让 Nginx 有读取权限。我踩过一次部署完页面 HTML 能打开但 CSS、JS 全部 404排查半天发现目录属主是 rootNginx 的www-data用户读不了。解决方式sudo chown -R www-data:www-data /var/www/bus_system/static/上传图片或导入 Excel 时更要注意MEDIA_ROOT目录权限。Django 写文件时用的是运行 Web 服务的用户如果 uWSGI 进程是 root 启动写出来的文件 root 所有后续要删除或覆盖就会权限混乱。规范做法是给 uWSGI 单独建一个低权限用户并确保上传目录归它所有。5.3 常见问题排查从迁移冲突到时区错乱这套资源在全新环境上容易碰到三个高频报错按现象、原因、解决来列报错一执行python manage.py migrate时提示django.db.migrations.exceptions.InconsistentMigrationHistory。原因是本地的migrations目录里留下了旧的历史迁移文件和数据表记录对不上。处理办法是备份数据库然后删除相关 app 的migrations文件重新跑makemigrations和migrate。如果数据重要可以先用python manage.py dumpdata导出再重建数据库。报错二OperationalError: (2002, Cant connect to local MySQL server through socket /var/run/mysqld/mysqld.sock)。原因是 MySQL 没启动或 Django 的settings.py里HOST配成了 localhost 导致 Python 走 socket 文件。解决方式确认service mysql status如果 MySQL 正常就把HOST改成127.0.0.1这样会走 TCP 而不是 socket。报错三后台录入的first_bus时间到了前端显示变成前一天晚上 8 点。这是非常典型的时区问题。在settings.py里要同时设置TIME_ZONE Asia/Shanghai和USE_TZ TrueMySQL 连接参数里还要加OPTIONS: {charset: utf8mb4}。如果你只是改了系统时区而不改TIME_ZONEDjango 会在存入 MySQL 时自动转 UTC读取时再转回本地时间显示就会错乱。这套资源在线路时间维护上就踩过这个坑我后来在处理任何时间字段前都先看一眼settings.py里这两行。6. 进阶接入 Redis 做实时车辆位置缓存降低数据库压力当你把车辆定位数据上报频率提高比如每 10 秒一次几十辆车同时写入bus表的last_longitude和last_latitudeMySQL 的update_time字段会频繁更新高峰期报表查询和位置更新互相锁等待。一个缓解思路是引入 Redis把车辆实时位置放缓存里MySQL 只做低频持久化。缓存模块大致长这样# apps/bus/cache.py import redis pool redis.ConnectionPool(host127.0.0.1, port6379, db0, decode_responsesTrue) client redis.Redis(connection_poolpool) def get_bus_position(plate_number): position client.hget(fbus_pos:{plate_number}, loc) if position: return position # 缓存未命中回源 MySQL bus Bus.objects.get(plate_numberplate_number) save_bus_position(plate_number, bus.last_longitude, bus.last_latitude) return f{bus.last_longitude},{bus.last_latitude} def save_bus_position(plate_number, longitude, latitude): client.hset(fbus_pos:{plate_number}, mapping{ loc: f{longitude},{latitude}, update_time: str(int(time.time())) }) client.expire(fbus_pos:{plate_number}, 60)这里用 Redis 的 hash 结构存位置每个车牌号对应一个 key过期时间 60 秒保证单条位置数据不会长期占用内存。查询车辆的实时位置时先查 Redis没有再去 MySQL 补这种方式能显著降低数据库的写读频率。注意decode_responsesTrue可以让 Redis 返回的字符串不被包裹成 bytes否则前端拼接坐标时会一直报类型错误。这套资源里没有直接集成 Redis所以二次开发时你需要自己启动 Redis 服务并在requirements.txt里加redis依赖。我建议在接入前先做一个开关在settings.py里写一个USE_REDIS True变量这样如果部署环境没有 Redis设置为 False 时系统仍能回落到 MySQL不至于直接崩。从那以后我每次拿到新项目都会强制走一遍这个检查流程先看settings.py时区和静态文件再看模型里时间字段类型最后再决定要不要加中间件——顺序错了后面往往要返工。这套公交系统源码本身骨架不错只要把表结构理解清部署时避开版本和静态文件两座大山剩下就是在业务逻辑上慢慢磨了。希望帮到你。本文还有配套的精品资源点击获取
