基于Django的智能停车系统毕设全攻略：从数据库设计到部署答辩

每年到这个时间点，总能看到一批同学在纠结毕设选题，其中“基于Python的智能停车系统的设计与实现”问的人尤其多。一方面Django做Web项目确实顺手，另一方面停车系统听起来不像电商、论坛那么烂大街，但真做起来又没那么简单。这篇内容我会结合自己开发Django毕设项目的完整经历，把智能停车系统从需求拆解、数据库设计、核心计费逻辑到远程调试、文档编排和答辩准备的各个环节都摊开讲一遍，给正在做同类题目或者准备做Web类毕设的同学一个可以直接参考的路线。

1. 智能停车系统到底要做什么：一个毕设项目的业务需求拆解

1.1 两条用户主线的业务闭环

很多人拿到题目就开始建表，结果做着做着发现功能之间对不上。我的建议是先跟着业务流程走一遍，把角色和动作理清楚，再动手写代码。智能停车系统最核心的无非是两类人：普通车主用户和管理员。

车主这条线是：注册登录 → 查看空闲车位 → 预约车位 → 到场停车 → 离场结算 → 查看历史停车记录。这条路本身就是完整的业务闭环，从“找车位”到“付钱走人”，每一步都对应一个功能点。

管理员这条线更偏后台管理：车位信息维护 → 费率设置 → 订单和预约管理 → 用户管理 → 统计报表（收入、空位率、热门时段等）。如果没有管理员后台，这个系统就只是一个“停车位展示页”，撑不起“智能”两个字。

所谓“智能”，落到毕设这个量级上，我理解就是三个能力：车位状态能实时变化、预约和入场出场能自动联动、计费能按规则自动计算而不是人工改价格。把这三条做扎实，功能上就站得住脚了。

1.2 模块拆解：功能清单不是越全越好

很多同学喜欢把功能表列得特别大，什么会员积分、优惠券、室内导航全往上堆。实际上毕设项目的评审老师更看重的是：每个功能是否真正实现了、逻辑是否闭环、代码是否你自己能讲清楚。

我建议按模块来规划，至少包含这几个核心模块：

我见过不少项目只做了“车位增删改查”，预约和计费用了一个字段硬凑，结果答辩被问两句就答不上来。所以功能宁缺毋滥，但模块之间的联动必须完整。

1.3 非功能需求：毕设项目最容易被忽视的部分

业务功能之外，还有几个非功能需求要提前定好，否则后面返工很痛苦。

第一是权限。普通车主和管理员看到的界面、能执行的操作必须分开，Django自带的分组和权限系统直接就能用，把管理员放进一个“manager”分组，在视图里用装饰器判断即可。

第二是响应速度。毕设虽然不要求高并发，但车位列表页、预约查询这种接口不能用多层循环去查数据库，能用select_related和annotate顺手优化就优化了。

第三是数据安全。用户密码不要自己写加密，直接用Django的User模型；删除操作尽量用软删除或者带确认弹窗，防止管理员手滑。

这些点平时不显眼，但写进文档里、演示的时候提一嘴，评审老师的印象会好很多。

2. 为什么偏偏是Django：技术选型背后的真实权衡

2.1 Django在毕设场景里的三个优势

选Django不是因为它最牛，而是因为它在“毕业设计”这个特定场景下太合适了。

第一个优势是自带Admin后台。做过Web开发的人应该知道，后台管理看起来简单，但真要写增删改查页面其实非常繁琐。Django的admin站点，只要把模型注册进去，一个能用的管理后台就有了，省下大量时间，而你完全可以把省下来的时间投入到预约计费这些核心逻辑上。

第二个优势是ORM和迁移机制。直接写SQL对不少同学来说容易出错，而Django的ORM把建表、改表变成了Python代码，migrate命令一键同步数据库结构。做毕设期间改字段太常见了，没有迁移机制的框架会让你改到怀疑人生。

第三个优势是生态成熟。用户认证、Session、表单处理、分页器都是开箱即用的，中文资料也最多，遇到问题一搜就能解决。真要说用Flask那种微框架，自由度高但我个人觉得毕设阶段没必要给自己增加工作量。

2.2 常见技术栈对比：别一拍脑袋选前后端分离

简单对比一下毕设里常见的几种组合：

前后端分离看起来很加分，但如果你对Vue不熟、又需要在一个月内同时写前端后端和论文，我劝你谨慎。Django模板加Bootstrap，配上一点原生JavaScript和AJAX，足够把交互做得不错。真要展示技术点，把预约流程做成不刷新页面异步提交，就已经能让评委眼前一亮了。

模板渲染还有一个实际好处：调试时不用开两个服务，一个python manage.py runserver就全搞定了，远程部署也简单得多。

2.3 “丰富项目”怎么理解：功能闭环比功能数量重要

我看到很多售卖的源码强调“丰富项目”，但“丰富”这个词我觉得要重新理解。一个模块能跑通完整链路，比堆十个互不关联的页面有价值得多。

以停车系统为例：车位从空闲变成预约，预约时间快到了变成占用，出场之后恢复空闲——这一个状态循环就把预约、入场、出场、计费四个模块串起来了。在文档里画一张状态流转图，在答辩时顺着这条链路讲，比挨个念功能列表更能说明你对系统的理解。

所以你在规划项目时，哪怕是增删改查，也要设计成“操作A会影响B，B又触发C”这种形式。这才是“系统”两个字的意义。

3. 数据库与核心业务逻辑：从建表到计费

3.1 四张核心表和它们之间的关系

开始写代码前，先把表结构想明白，后面会少走很多弯路。我最终精简到四张核心表：

• User：继承Django的AbstractUser，额外加一个手机号和车牌号字段
• ParkingSpace：车位表，记录车位编号、所在区域、状态
• Reservation：预约表，记录用户、车位、预约时间段、状态
• ParkingRecord：停车记录表，记录用户、车位、入场时间、出场时间、费用

其中ParkingRecord是后来补上的，也是最关键的一张表。很多初版设计把停车记录和预约混在一起，结果超时停车、未预约直接入场这些情况根本没法表达。分开之后，每次停车行为都对应一条记录，计费逻辑写在记录上，清晰很多。

写模型的代码大致长这样：

python复制from django.db import models
from django.contrib.auth.models import AbstractUser

class User(AbstractUser):
    phone = models.CharField('手机号', max_length=11, unique=True)
    car_number = models.CharField('车牌号', max_length=20, blank=True)

    class Meta:
        verbose_name = '用户'
        verbose_name_plural = verbose_name

class ParkingSpace(models.Model):
    STATUS_CHOICES = (
        ('idle', '空闲'),
        ('reserved', '已预约'),
        ('occupied', '已占用'),
    )
    code = models.CharField('车位编号', max_length=10, unique=True)
    location = models.CharField('所在区域', max_length=100)
    status = models.CharField('状态', max_length=10,
                              choices=STATUS_CHOICES, default='idle')
    created_at = models.DateTimeField(auto_now_add=True)

class Reservation(models.Model):
    STATUS_CHOICES = (
        ('pending', '待使用'),
        ('used', '已使用'),
        ('cancelled', '已取消'),
        ('expired', '已过期'),
    )
    user = models.ForeignKey(User, on_delete=models.CASCADE,
                             verbose_name='用户')
    space = models.ForeignKey(ParkingSpace, on_delete=models.CASCADE,
                              verbose_name='车位')
    start_time = models.DateTimeField('开始时间')
    end_time = models.DateTimeField('结束时间')
    status = models.CharField('状态', max_length=10,
                              choices=STATUS_CHOICES, default='pending')

class ParkingRecord(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE,
                             verbose_name='用户', null=True, blank=True)
    space = models.ForeignKey(ParkingSpace, on_delete=models.CASCADE,
                              verbose_name='车位')
    start_time = models.DateTimeField('入场时间')
    end_time = models.DateTimeField('出场时间', null=True, blank=True)
    amount = models.DecimalField('费用', max_digits=8,
                                 decimal_places=2, default=0)

注意所有外键查询都用related_name或者直接通过ORM反向查询，别在模板里裸写一大堆嵌套查询，后期维护会非常痛苦。

3.2 车位状态流转：一个简单的状态机

车位状态看似简单，但很容易写出“状态只存不改”的假系统。我的做法是把状态变更收敛到专门的service函数里，所有入口都走函数，而不是在视图里直接改space.status。

状态流转的核心逻辑就是三个动作：

1. 预约成功：idle → reserved
2. 入场确认（或预约到期自动入场）：reserved → occupied
3. 出场结算：occupied → idle

这里不需要过度设计，用简单的判断加事务就能保证一致性。真正要注意的是“预约之后超时没来怎么办”。我在系统里加了一个判断函数：在查询预约列表时，如果当前时间大于end_time且状态是pending，就自动把状态更新为expired，同时把车位恢复成idle。懒加载的思路，不用定时任务也能处理大部分过期预约，对毕设来说足够了。

3.3 计费逻辑：我用Decimal解决了浮点精度问题

计费是智能停车系统的灵魂，也是最容易翻车的环节。我做第一版时用FloatField存金额、用浮点数加减乘除，结果用户连续停车几十次之后，总金额出现奇怪的0.000004这样的尾巴。后来全部换成DecimalField和Decimal运算才彻底解决。

计费规则按阶梯设计：前半小时免费，半小时到一小时收5元，超过一小时后每小时加收3元，不足一小时按一小时算。计算函数如下：

python复制from decimal import Decimal

def calculate_parking_fee(record):
    """根据停车记录计算费用，阶梯计费"""
    if not record.end_time:
        return Decimal('0.00')

    duration = record.end_time - record.start_time
    minutes = duration.total_seconds() / 60

    # 前30分钟免费
    if minutes <= 30:
        return Decimal('0.00')
    
    # 半小时到一小时
    if minutes <= 60:
        return Decimal('5.00')

    # 超过一小时，按整小时向上取整
    extra_hours = (minutes - 60 + 59) // 60  # 向上取整
    amount = Decimal('5.00') + Decimal('3.00') * int(extra_hours)
    return amount

这里的坑一个是时间差计算，total_seconds()拿到的是浮动秒数，要除以60转成分钟；另一个是向上取整的写法，直接用math.ceil也行，但整数整除(a + b - 1) // b这种写法更直观也不需要在文件顶部再导包。

计费费率我单独弄了一张表，把起步价、免费分钟数、超时单价都存进去，管理员可以在后台改。这样答辩的时候你就可以说“费率可配置”，比写死参数听起来专业得多。

3.4 并发预约：select_for_update锁住那条记录

预约场景里有一个隐藏问题：两个人同时看中同一个车位，同时提交预约，如果代码没做并发控制，就会出现两边都显示预约成功，但一个车位不可能同时给两个人。

做毕设可能不会真的遇到高并发，但老师问起来你要答得出来。从并发的角度考虑，最简单的方案是在事务里锁定车位记录：

python复制from django.db import transaction

def create_reservation(user_id, space_id, start_time, end_time):
    with transaction.atomic():
        # 锁住车位记录，防止并发修改
        space = ParkingSpace.objects.select_for_update().get(id=space_id)
        if space.status != 'idle':
            raise ValueError('该车位已被预约或占用')

        # 状态改为已预约
        space.status = 'reserved'
        space.save()

        Reservation.objects.create(
            user_id=user_id,
            space_id=space_id,
            start_time=start_time,
            end_time=end_time,
            status='pending'
        )
        return True

select_for_update在数据库层面生成SELECT ... FOR UPDATE，事务提交前，另一条预约请求会一直等待，等锁释放后读到最新的状态，自然就不会重复预约了。这个知识点在论文的“系统安全与并发处理”章节里写上，是很好的加分点。

4. 实战中最容易翻车的四个细节：时区、钱、并发和静态文件

4.1 时区与时间：USE_TZ的正确打开方式

这是所有Django新手几乎都会踩的坑。开发时本地时间显示正常，一到服务器上，所有时间都差8小时，预约记录的时间全部不对。

根因是Django的settings里默认USE_TZ = True，此时数据库存的是UTC时间，模板渲染时Django会依据TIME_ZONE设置转成当地时间。如果你只改了TIME_ZONE = 'Asia/Shanghai'但忘了USE_TZ = True，或者反过来记了时间但不会转换，都会出问题。

我在settings里的配置是这样的：

python复制TIME_ZONE = 'Asia/Shanghai'
USE_TZ = True

关键是在代码里写时间一定要用django.utils.timezone.now()，而不是datetime.datetime.now()：

python复制from django.utils import timezone

now = timezone.now()  # 正确

如果你确实需要在特定场景下拿到本地时间，就localtime = timezone.localtime(timezone.now())。排查这种问题时，我建议先启动Django shell，打印一遍数据库里的时间，再打印一遍渲染出来的时间，基本一眼就能看出来是存储层的问题还是展示层的问题。

4.2 金额与精度：为什么不能用FloatField

这个前面已经说了，我再补一个具体场景。停车费用算到“元”这个层级还没太大事，但一旦涉及优惠、阶梯价格、退款，浮点误差就会积累。比如0.1 + 0.2在浮点数里等于0.30000000000000004，这不是Django的问题，是计算机二进制的固有限制。

所有涉及钱的地方必须遵守三条规矩：模型字段用DecimalField，代码运算用decimal.Decimal，对外接口输出时再转字符串或四舍五入到两位小数。

Decimal做除法时还要注意精度上下文，比如金额除以分钟数，直接用Decimal('5.00') / Decimal('60')会报InvalidOperation，需要先getcontext().prec = 8或者改用Decimal(str(y))。这些坑不算难，但遇到一次就会让人头大。

4.3 并发与状态：同一车位被两个人同时预约

除了select_for_update，我还会在逻辑层面做“状态前置校验”的兜底。也就是说，即使锁没有生效，代码里也必须先判断space.status == 'idle'再允许预约，而不是直接在不知道当前状态的情况下裸写space.status = 'reserved'。

另外，预约表单提交用的是POST请求，前端要做好防止重复提交的处理，比如点击预约按钮后立刻禁用按钮并显示“提交中”。这样做不是因为毕设项目会有人真去并发刷接口，而是为了展示你对这类问题的完整思考过程。

如果觉得事务和锁理解起来有压力，也可以用代码轮询的简化方案：预约前先查一次状态为空闲，再改状态，极端情况下可能会闪失，但毕设演示完全够用。不过为了答好答辩，还是建议把事务方案写进代码里。

4.4 静态文件：本地能跑，换台机器就白屏

Django开发时静态文件能正常加载，是因为runserver自动帮你处理了静态文件。但一旦把DEBUG改成False，或者部署到服务器用Gunicorn跑，CSS和JS全部消失，页面就成纯文字了。

解决办法是配置好STATIC_ROOT和STATICFILES_DIRS，然后在服务器上执行python manage.py collectstatic。如果要简单点，可以在本地先汇总一次静态文件，把staticfiles整个目录一起上传部署：

python复制STATIC_URL = '/static/'
STATICFILES_DIRS = [os.path.join(BASE_DIR, 'static')]
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

部署时如果用Nginx，建议直接让Nginx接管/static路径，Gunicorn只处理动态请求，这样性能最好也不容易出错。如果只是临时给别人演示，python manage.py runserver 0.0.0.0:8000 --insecure也能凑合，但不建议作为正式方案。

5. 从能跑到能过审：文档、演示和远程调试的实操建议

5.1 你的毕业设计文档别写成用户手册

源码可能只占毕设总评分的三四成，文档和答辩占大头。很多同学把论文写成了“安装说明+功能截图”，这种写法基本就是给评审老师一个充分的理由扣分。

我的论文结构是这样安排的：摘要 → 绪论（背景、国内外现状、研究意义）→ 需求分析（功能需求、非功能需求、用例图）→ 系统设计（总体架构、功能模块划分、数据库设计、关键算法设计）→ 系统实现（每个模块的代码和界面截图）→ 系统测试（测试用例表格、测试结果）→ 总结与展望。

其中数据库设计要有ER图或者表结构对比表，关键实现要贴上计费、并发控制这种能体现难度的代码片段，测试章节最好按模块列测试用例，展示你确实测过完整流程。

如果你拿到的源码已经附带了文档，也别直接提交。先对照自己选用的数据库、修改过的字段做一次全文修订，保证代码和文档一致，否则答辩时老师照着文档问你代码，对不上就尴尬了。

5.2 演示脚本：五分钟讲完整个项目

毕设演示最忌讳照着PPT念，或者临时登录系统现场乱点。我建议提前写一个五分钟演示脚本，走完整链路：

管理员登录 → 展示车位列表和统计页面 → 修改费率 → 切到车主账号 → 搜索空闲车位 → 发起预约 → 模拟入场（车位变占用）→ 模拟离场 → 展示生成的停车记录和费用 → 回到管理员后台看订单记录。

整个过程其实就是把“1.1 业务闭环”那条链路再走一遍，边点边讲每一步对应的表结构、状态变化和设计理由。评委最想听到的不是“这里写了一个查询”，而是“这里为什么这样设计、遇到什么困难怎么解决的”。

如果你做的是“全套源码+文档+远程调试”这种服务型交付，演示前一定要在目标机器上把环境完整跑一遍，Python版本、依赖库版本都确认无误，不要把调试时间浪费在现场。

5.3 远程调试与部署：让项目在不同环境下跑起来

很多同学在本地跑得很流畅，一到别人的电脑或者服务器上就各种问题。远程调试和部署其实是同一个问题：环境一致性。

我常被问到“远程调试”这个服务到底怎么拉通。简单说，就是让开发者的电脑和目标服务器能在同一套代码上协作。最基础的做法是，服务器上装好Python、创建虚拟环境、安装项目依赖，然后把runserver绑到0.0.0.0:8000；网络层如果有限制，再配合SSH隧道把远程端口映射回本地，本地就能像访问http://127.0.0.1:8000一样访问服务器上的Django服务。

如果直接用VSCode开发的，可以用VSCode的Remote-SSH插件直接连到服务器编辑代码，断点调试时在Django的入口文件里加一个debugpy的监听器，本地VSCode会附着上去，调试体验和在本地几乎一样。

这里有一个非常核心的建议：远程调试的所有操作都要先确定好依赖锁定文件。我在项目的根目录放了requirements.txt，各种关键的第三方库都锁定了版本（比如Django 4.2.x、Pillow版本等）。不锁定版本的后果就是，服务器自动装了最新版Django，跟本地代码语法对不上，一启动就报错，排查几天都找不到原因。

5.4 答辩追问：准备好这几个问题的回答

最后一步是答辩。老师问来问去基本就那么几类问题：技术选型理由、某个功能怎么实现、遇到什么难点、有没有考虑并发或者安全。提前准备几个高频问题的口语化回答，比临场编靠谱得多。

回答时尽量往“我实际遇到并解决过”上靠，哪怕问题本身不难，真诚地描述解决过程也比背理论强。

写在最后的小经验

这套系统我前后做了三版才真正觉得拿得出手，最大的体会是：毕设项目的价值不在功能数量，而在逻辑闭环和技术细节。你愿意把状态流转、并发处理、时间精度、金额精度这些细节打磨好，它就不只是一个交差的作业，而是可以在简历里写上一笔的实战经历。

如果时间有限，我建议你按优先级排：数据库设计 → 预约计费闭环 → 后台管理 → 统计图表 → 用户体验优化。前面几步决定了系统的硬实力，后面的只是锦上添花。

最后再分享一个后续扩展方向：给系统加一个简单的车牌识别入口，比如用OpenCV读入场摄像头返回的车牌号，直接匹配预约信息自动完成入场登记。哪怕只是做了接口预留和模拟实现，在“智能”这个词上的完成度又会上一个台阶。希望这篇内容能帮正在做智能停车系统毕设的同学少走一点弯路，祝你们顺利过审。