停车管理系统开发全解析：从业务建模到SSM/Django部署实战

停车管理系统这个选题，在课设和毕设里可以说是常青树了。一方面它的业务逻辑足够完整，覆盖常见信息管理系统的全部套路，能体现增删改查之外的流程设计能力；另一方面又不像电商、秒杀系统那么复杂，一个学期内完全能实现。最近我帮人梳理过一套基于Java+SSM+Django的停车管理系统，项目包里同时含有源码、LW（论文文档）、调试文档和讲解视频，看起来东西很全，但第一次接触的同学往往一打开就懵了：不知道从哪里看起，也不知道这些代码到底是怎么配合的。这篇文章我就把这类系统从需求到部署的完整思路捋一遍，顺便说说那些调试文档里通常不会明说的坑。

先说结论：所谓"基于Java+SSM+Django的停车管理系统"，本质上是一个车位资源调度 + 停车计时计费 + 订单记录追溯的业务系统。理解了这句话，后面所有代码和表结构都是顺理成章的事。下面我按实际开发顺序，从需求拆解到表结构设计，再到核心业务代码和部署联调，一条线讲透。

1. 停车场系统到底在管什么：先想清楚需求和业务边界

1.1 不要一上来就写代码：先把角色和场景列清楚

我刚带这类项目的时候，经常发现学生第一件事是打开IDE建工程，这其实是最容易返工的做法。做系统之前，先花半小时把"谁在用、怎么用"想明白。

一套典型的停车管理系统，至少有三类使用角色：

• 超级管理员：管理整个停车场的基本信息，维护收费标准，查看全量订单和统计报表。
• 前台/收费员：处理车辆入场登记、出场结算、现金收费，处理月卡办理等日常操作。
• 普通车主用户：查询车位余量、预约车位、查看自己的停车记录、在线缴费（如果系统是前后端分离或带H5端）。

从真实场景看，停车场还分很多种：商业综合体地下停车场、小区固定车位停车场、路边临时停车位。不同场景的计费模式差异很大：临时车按时长收费，月租车按月收费，有的还有夜间封顶、免费时长、新能源车优惠。这些业务规则如果一开始不确认清楚，后面设计数据库表的时候就会反复改。

1.2 从进场到离场的完整链路：流程决定了一切设计

这个系统最核心的一条主流程是这样的：

车辆进场 -> 登记车牌（人工录入或识别）-> 分配车位 -> 开启计时 -> 车辆出场 -> 校验车牌和订单 -> 计算停车费用 -> 支付结算 -> 释放车位

就是这条看似简单的链路，决定了整个系统怎么设计。注意几个关键点：

1. 进场和出场是系统最重要的两个事务，它们操作了多张表（车辆、订单、车位状态），必须保证一致性。
2. 计费发生在出场时，不是入场时，所以订单表要经历从"进行中"到"已完成"的状态流转。
3. 车位是共享资源，同一时刻只能被一辆车占用，这涉及并发控制，后面我会专门讲。

除了主流程，还有车位管理（增删改查、锁定预留）、订单查询、收费规则配置、统计报表等辅助流程。把这些整理成一个简单的功能清单，再开始建表和写代码，效率和正确性都会高很多。

2. SSM和Django两套方案，为什么同时出现在一个项目里

2.1 SSM这条技术线：Spring管对象、SpringMVC管请求、MyBatis管SQL

SSM是Spring + SpringMVC + MyBatis的组合。在停车管理系统里，这三者各自的分工非常清晰：

• Spring：负责管理Service层和Mapper层对象的创建和装配，也就是IoC容器。同时用AOP统一处理事务，比如支付、入场、出场这类需要同时更新多张表的操作，一旦中途出错就回滚。
• SpringMVC：负责HTTP请求的分发，从前端页面或接口过来的请求经过DispatcherServlet，找到对应的Controller方法，然后把JSON或者页面视图返回给前端。
• MyBatis：负责SQL语句和Java对象的映射。你可以把SQL写在Mapper.xml文件里灵活控制，也可以直接用注解，比如根据车牌号查车辆、修改车位状态这些操作，写成SQL执行就好。

这套组合的优点是层次分明，Controller、Service、Mapper三层结构对初学者非常友好，而且Java方向的学校里普遍讲这套技术栈，面试的时候也常问。缺点是配置偏多，各种XML文件容易让人看晕。

2.2 Django这条技术线：ORM、Admin后台、模板渲染三件套

Django版本的实现思路和SSM完全不同。Python的Django框架自带ORM（对象关系映射），你直接用Python类定义表结构，类名和字段对应数据库表名和列明。查询操作也非常直接，比如查正在进行的订单：

python复制order = ParkingOrder.objects.filter(vehicle__plate_no=plate_no, status=1).first()

再比如删除无用的测试车辆：

python复制Vehicle.objects.filter(plate_no="测试车牌").delete()

整个代码风格很简洁，新手也能很快读懂。Django还自带Admin后台，登录之后可以直接在网页里维护车位数据、查看订单，这在课设演示的时候效果很好——你甚至不用额外开发一套后台管理页面，Admin就能覆盖大部分管理需求。模板系统也能用来做普通的服务端渲染页面，如果做成前后端分离，配上Django REST Framework写接口也很顺手。

2.3 到底选哪套：对比之后你就明白了

同一个项目包里为什么会有两套实现？说到底是因为不同学校、不同导师对技术栈的要求不一样。有的要求Java方向，你交SSM的；有的课设指定Python方向，你交Django的。两套版本核心业务相同，但技术路径不同，你可以根据自己的方向选一套深入，另一套作为论文里的技术对比。

我的建议是，如果导师没有硬性指定，你对Python更熟就选Django，SSM那套留着做对比分析；如果未来想走Java方向，就老老实实啃SSM，毕竟Java面试里Spring容器、SpringMVC流程、MyBatis缓存这些话题出现频率真的很高。

3. 数据库设计：车位状态、停车订单与计费规则怎么建模

3.1 五张核心表，撑起整个系统

接下来是数据库设计。很多同学的第一个问题是"要建几张表"，实际上对于一个停车管理系统，核心表大概就是五张，配套的表再视情况增加。

我先给出一个实用性最强的表结构参考：

这里我要强调几个容易被忽视的细节：

第一，车位表的status字段一定要考虑"锁定"状态。实际停车场里总有预留车位、维修车位，如果状态只有空闲和占用两种，这类需求就没法支持。我习惯用字符串枚举：free（空闲）、occupied（占用）、locked（锁定），可读性好，查询也方便。

第二，车型要区分临时车和月租车。临时车按次计费，月租车按月卡有效期判断，这两个逻辑相差很远。我在vehicle表里通常会加一个vehicle_type字段，0表示临时车、1表示月租车，出场计费时先判断这个字段。

第三，订单表要有两个维度确认状态。停车订单有业务状态和支付状态，至少包含status（进行中/已完成/已取消）和pay_status（未支付/已支付）。有些同学只用一个status字段，后面做支付功能时就发现没法区分"已出场未付款"和"已付款历史记录"，还是要回过来改表。

3.2 车位状态流转：并发情况下如何避免重复分配

这是整个系统里最有技术含量、也是答辩时老师最爱问的一个点：两个车辆同时进场，怎么保证不会分配到同一个车位？

如果代码写成"先查一个空闲车位，然后更新它为占用"，那并发请求下就是经典的竞态条件（race condition）问题。两个请求同时查到空闲车位1号，然后都去更新，一辆车实际占用了车位，另一辆车的记录却显示也在1号位。

正确的做法是把"查询+更新"合并成一个原子操作，直接用条件更新（CAS，Compare And Set）的思路：

sql复制UPDATE parking_space SET status = 'occupied' WHERE id = #{spaceId} AND status = 'free'

在SSM的MyBatis里这样写：

java复制public int occupySpace(Integer spaceId) {
    return parkingSpaceMapper.updateStatusById(spaceId, "occupied", "free");
}

然后在Service层判断影响行数：

java复制boolean success = occupySpace(spaceId) == 1;
if (!success) {
    // 这个车位已被占用，重新分配
    throw new BusinessException("车位已被占用，请重新分配");
}

Django里的ORM写法更直接：

python复制updated = ParkingSpace.objects.filter(id=space_id, status="free").update(status="occupied")
if updated == 1:
    # 分配成功
    pass

这里的精髓在于AND status = 'free'。只要更新影响行数为0，说明这个车位状态已经不是空闲了，直接换下一个车位即可。这个技巧在写论文的时候一定要写进去，是很加分的实战细节。

3.3 收费规则表：别把价格写死在代码里

停车收费是本系统的业务核心。很多课设会把价格常量直接写在Java的类里或者Python的配置文件里，比如"首小时5元，之后每小时2元"。这样做最大的问题是：换个停车场、或者同一停车场改收费标准，必须改代码重新部署。

更好的做法是把收费标准设计成数据库表，也就是charge_rule表。字段含义大概是：

• free_minutes：免费分钟数，比如前15分钟免费
• first_hour_price：首小时价格
• unit_price：超出首小时后每单位时间价格
• unit_minutes：单位时间分钟数，比如每30分钟2元
• daily_cap：24小时内最高收费（日封顶）

用户维护收费标准，后台对订单进行计费时，动态读取规则计算。从SSM的层面来说，就是一个ChargeRuleMapper的查询操作；从Django的层面来说，是Model.objects.get()。新增一个"元旦活动价"或者"新能源半价"规则，完全不用改代码，这就是可配置设计的意义。

4. 核心功能实现：车辆进出场与费用结算到底怎么写

4.1 车辆入场：登记车牌、分配车位、开启计时

入场接口是整个系统里逻辑最完整的一个接口。我在实际写代码时，会按下面的步骤组织Service层方法：

1. 根据车牌号查询车辆是否存在，不存在则创建一条车辆记录。
2. 查询该车辆是否存在"进行中"的订单，防止同一辆车重复入场。
3. 从车位表里查一个空闲车位，用前面说的条件更新方式占用它。
4. 创建停车订单，记录entry_time = 当前时间、status = 进行中。
5. 返回分配的车位号给前端展示。

用伪代码描述就是：

code复制def vehicle_entry(plate_no):
    vehicle = get_or_create_vehicle(plate_no)
    if exists_ongoing_order(vehicle.id):
        raise error("该车辆已在场内")
    space = find_free_space()
    if occupy_space(space.id) == 0:
        raise error("车位分配失败")
    create_order(vehicle.id, space.id)
    return space.space_no

这里还需要注意一个细节：车位分配成功和订单创建这两个操作要保证原子性，也就是说车位被占用但订单创建失败时，要把车位释放掉。SSM里用@Transactional注解包住整个方法，Django里用transaction.atomic()上下文管理器。这个细节在论文里很值得写，体现的是事务一致性的思想。

4.2 车辆出场：计算时长、匹配规则、生成账单

出场逻辑和入场逻辑对称，但多了一个计算费用的部分。我的实现步骤是：

1. 根据车牌号查出"进行中"的订单。
2. 更新订单的exit_time = 当前时间，计算停车时长。
3. 读取收费规则，按规则计算出费用。
4. 更新订单金额和状态，设置订单为已完成、未支付。
5. 把对应的车位状态改回空闲。
6. 返回订单详情和应缴金额给前端收银台。

时长计算在Java里推荐用LocalDateTime和Duration：

java复制Duration duration = Duration.between(order.getEntryTime(), LocalDateTime.now());
long minutes = duration.toMinutes();

Django里则直接在Model里定义方法：

python复制from datetime import datetime
duration_minutes = (datetime.now() - order.entry_time).total_seconds() // 60

计费逻辑用一个单独的方法来做，便于测试和复用。基本思路是：

code复制停车时间小于等于免费时长 -> 费用为0
否则：
  超出时间 = 总时长 - 免费时长
  费用 = 首小时费用
  若 超出时间 > 60分钟：
    费用 += ceil((超出时间 - 60) / 单位分钟数) * 单位价格
  若 设置了日封顶 且 费用 > 日封顶：
    费用 = 日封顶

写成Java伪代码：

java复制public BigDecimal calculateFee(ChargeRule rule, long minutes) {
    if (minutes <= rule.getFreeMinutes()) {
        return BigDecimal.ZERO;
    }
    long extra = minutes - rule.getFreeMinutes();
    BigDecimal fee = rule.getFirstHourPrice();
    if (extra > 60) {
        long extraUnits = (long) Math.ceil((extra - 60) / (double) rule.getUnitMinutes());
        fee = fee.add(rule.getUnitPrice().multiply(BigDecimal.valueOf(extraUnits)));
    }
    if (rule.getDailyCap() != null && fee.compareTo(rule.getDailyCap()) > 0) {
        fee = rule.getDailyCap();
    }
    return fee;
}

注意这里用BigDecimal而不是double来计算金额，浮点数在做金额运算时有精度问题，这个习惯最好从一开始就养成。

4.3 后台功能：车位管理、订单查询与统计报表

除了进出场，后台管理功能占据了系统代码量的一大部分。这块本质上就是常规的信息管理功能：

• 车位管理：车位的增删改查，手动把车位设为锁定或空闲。比较好用的是车位状态看板，一页展示所有车位，用不同颜色区分状态，配合ECharts做一个小可视化，演示效果会好很多。
• 订单查询：按车牌号、入场时间范围、订单状态筛选。在SSM里写一个多条件的动态SQL，MyBatis用<where>标签拼接；Django里用filter()链式调用配合Q对象。
• 统计报表：今日收入、当前在场车辆数、车位利用率。SQL层面就是SUM、COUNT、GROUP BY，在Service层聚合返回给前端展示。

从代码量来看，后台管理功能占了差不多一半，但难度不大，把这些做完之后，整个系统在功能完成度上就没什么短板了。

5. 部署联调时最容易踩的坑：从源码到能跑起来

5.1 环境准备：两个技术栈各自的依赖清单

拿到项目源码后，最大的挑战往往不是看不懂代码，而是环境跑不起来。SSM版和Django版依赖不同的运行环境，我分别列一下：

SSM版需要准备：

• JDK 8或11，配置好JAVA_HOME
• Maven 3.6+，配置好阿里云镜像加快依赖下载
• MySQL 5.7或8.0，创建数据库并导入SQL脚本
• Tomcat 8.5+（如果用外置容器），或者使用SpringBoot内嵌Tomcat的方式

Django版需要准备：

• Python 3.8+，建议用venv创建虚拟环境
• pip install -r requirements.txt安装依赖，常见的是Django、MySQLclient、PyMySQL、django-cors-headers
• python manage.py migrate生成数据表，再执行数据初始化脚本
• python manage.py runserver启动开发服务器

这套流程本身不复杂，但经常有人卡在数据库连不上或者依赖版本冲突上。

5.2 配置文件的坑：数据库连接、静态资源与跨域

第一个最常见的坑是 数据库连接URL的编码和时区参数。中文乱码、时间差8小时，十有八九是这里的问题。MySQL连接串我建议直接复制这份：

code复制jdbc:mysql://localhost:3306/parking_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

characterEncoding=utf8保证中文不乱码，serverTimezone=Asia/Shanghai保证时间正确，useSSL=false避免握手警告。这个问题在Django版的settings.py里对应的是：

python复制DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'parking_db',
        'USER': 'root',
        'PASSWORD': 'your_password',
        'HOST': '127.0.0.1',
        'PORT': '3306',
        'OPTIONS': {'charset': 'utf8mb4'},
    }
}

第二个坑是静态文件加载不出来。Django里模板引用了CSS、JS、图片，页面打开却是裸奔的。原因通常是忘记配置STATICFILES_DIRS，或者模板里没有加{% load static %}。在settings.py里加上：

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

模板里引用静态文件时用{% static 'css/style.css' %}。

SSM版如果用的JSP或者独立前端页面，则要注意SpringMVC的静态资源放行配置，CSS/JS路径别被DispatcherServlet拦截成404：

xml复制<mvc:resources mapping="/static/**" location="/static/"/>

第三个坑是跨域问题。如果前端页面独立部署在8081端口，Java后端在8080，或者Django后端在8000，浏览器就会拦截跨域请求，报CORS错误。SSM后端可以在Controller上加@CrossOrigin，更正规的是写一个CORS过滤器统一配置。Django版则安装django-cors-headers，在MIDDLEWARE里加上corsheaders.middleware.CorsMiddleware，并配置允许的源。

5.3 联调检查清单：演示前照着过一遍

项目跑起来之后，我建议按下面这个清单完整走一遍流程，别等到答辩演示时才手忙脚乱：

• [ ] 数据库已导入，连接正常，中文无乱码
• [ ] 管理端账号能登录，能正常登出
• [ ] 能新增、编辑、删除车位
• [ ] 模拟入场：录入车牌，能分配车位，车位状态变为占用
• [ ] 模拟出场：录入同一车牌，能计算费用，订单生成，车位状态变为空闲
• [ ] 用另一套前端页面（如果有）确认跨域配置生效
• [ ] 检查讲解视频/PPT里的截图和当前系统页面是否一致

这个清单里最后一条特别重要。很多项目包里的LW（论文文档）里有截图，但如果你改了代码或者界面，截图对不上，答辩时被问到会很尴尬。尽量让代码和文档保持一致。

6. 做完这个项目之后，我的一些实际操作体会

6.1 金额精度、时间边界与跨天计费

计费模块是整个系统里最容易出Bug的地方，我在这方面踩过不少坑。

第一是金额精度。金额计算永远不要用float或double，一定要用BigDecimal（Java）和Decimal（Python的decimal模块），数据库里对应使用DECIMAL(10,2)字段。浮点数的0.1+0.2不等于0.3这种问题，出现在停车费上就是给用户算错钱。

第二是时间边界。免费时长为15分钟时，停车15分0秒和15分59秒的判定就不同。我的经验是统一按分钟取整，不足一分钟按一分钟算，或者完全按秒数比较，总之规则要前后一致，并且写进文档里。

第三是跨天计费。停车时长跨越零点时，"日封顶"怎么计算？是按自然日拆分，还是按入场后24小时算？这个没有标准答案，但你的系统里必须有明确规则。如果规则表里设计的是"按自然日封顶"，那么跨天订单要拆成两条记录分别计算，或者单独处理。答辩时老师很爱问这类边界问题，答得出来就是加分项。

6.2 车牌识别：现实项目里对接的到底是什么

很多同学以为"停车管理系统"里必须包含车牌识别算法，其实绝大多数的系统接入的是第三方识别能力：停车场出入口的摄像头硬件自带识别芯片，通过SDK或HTTP接口把识别结果（车牌号字符串）传给后台系统。你在后端要做的只是接收这个字符串，然后走查车、分配车位、开订单的流程。

所以课设里做一个手动输入车牌号、或者用下拉列表模拟车牌识别的交互，是完全合理的。在论文里可以这样写：预留车牌识别接口，实际部署时可对接大华、海康等厂商的SDK。这样的表述既诚实又符合行业实际情况。

6.3 拿到源码之后怎么读、怎么改、怎么讲

项目包里源码、论文、调试文档、讲解视频都有，但很多同学拿到之后反而不知道从哪里下手。我的建议是按这个顺序来：

1. 先看数据库脚本。把表结构看明白，理解停车场、车位、车辆、订单、收费规则之间的关系。
2. 看路由或URL配置。知道系统有哪些功能入口，哪些Controller/View对应哪些页面。
3. 找一个最小闭环走一遍。比如"车辆入场"，从点击按钮开始，到Controller、Service、Mapper/ORM，每一步做了什么，返回了什么。
4. 确保代码能在自己电脑上跑起来，再动手改。改的时候小步走，改一个功能就测一次，别等全改完了再调试，那样出问题根本定位不到。

最后关于讲解：演示的时候不要只顾着点功能，要把字段设计、事务控制、并发更新这几个技术点主动讲出来。老师问"这个系统有什么难点"的时候，你说"用了CAS思想解决并发下车位重复分配的问题"，比"我用了SSM框架"要亮眼得多。这也是我反复强调条件更新的原因——它不仅是技术方案，更是答辩现场最好的展示素材。