停车场管理系统毕业设计：数据库设计与跨天计费逻辑完整剖析

简介毕业设计《停车场管理系统》完整项目包面向计算机相关专业学生与开发者覆盖车位管理、车辆进出、费用结算等核心业务适用于校园、商业区等典型停车场景是毕业设计或课程设计的实用参考。资源包共592个文件压缩后142.93MB主要包含89个Java源文件、184个class编译文件、135个XML配置与界面文件、66个JAR依赖库另有HTML、JavaScript、JSP页面、SQL数据库脚本及Git仓库文件几乎涵盖Web系统从后端逻辑、前端交互到数据库设计的完整技术栈其中Java文件对应业务逻辑、XML负责配置与视图、SQL提供数据表结构。已有2528人学习内容提供完整工程代码、数据库脚本与配置信息可帮助读者梳理车牌识别、计费处理、RESTful接口、用户权限等模块的实现方式也能在此工程基础上进行二次开发与功能扩展是综合运用数据库、软件工程与AI技术的较好范例。1. 毕业设计停车场管理系统为什么年年有人选年年有人卡在答辩前停车场管理系统是毕业设计里出现频率最高的几类选题之一因为它的业务边界清晰车辆入场、出场、计费、会员管理、报表统计。看起来就是一套标准的增删改查很多同学选它图的是稳妥。但真做到中期答辩前后才发现最容易翻车的也正是这种“看起来简单”的题目——数据库表设计不合理导致计费金额对不上账硬件设备异步回调导致出场时找不到入场记录跨天停车把跨天计费算成一笔糊涂账。真正能让人信服的停车场管理系统不是把页面做出来就完事而是把车辆状态流转、计费规则、异常订单处理这三件事理顺。这篇笔记我按自己做过的一个模拟项目X的完整思路来讲从技术选型、表结构、核心计费逻辑、前端页面到高频踩坑点全程可以照着复现适合正在做这个题目的同学也适合想快速搭一套可演示原型的朋友。2. 技术选型与系统架构先把方案定死再动手写代码2.1 单体应用还是前后端分离停车场管理系统如果只在本地演示用单体架构反而比前后端分离更省事。常见做法是先用一个Spring Boot的Web应用承载所有接口和页面渲染配合Thymeleaf做服务端页面。这么做的好处是部署简单、答辩演示时不容易因为前端跨域配置把页面调挂。如果后续想扩展成小程序或平板端再把接口层单独拆出来也不迟。我见过不少同学一上来就搞Vue加Spring Boot分离架构结果CORS配置、Token过期处理、打包静态资源就耗掉一周。对于毕业设计这个体量数据库表不超过二十张、并发量按单台道闸设备处理单体应用完全扛得住。2.2 数据库选型与部署位置数据库首选开源的MySQL版本选5.7或8.0都行重点是把utf8mb4字符集固定下来别用默认的latin1不然车辆的车牌号里有汉字或者生僻字时存进去就是乱码。部署位置建议直接装在本地电脑上不要为了显得高级去搞云数据库。答辩现场一旦网络波动整个演示就变成“系统打不开”这种场面很尴尬。如果导师要求必须有网络版效果可以在自己电脑上装一个内网穿透工具来临时演示但别把它当作正式部署方案因为隧道服务不稳定。2.3 硬件设备对接识别一体机与道闸的两种连接方式停车场管理系统最大的不确定性来自硬件层。常见做法是选一体机设备也就是集成了车牌识别摄像头和道闸控制模块的机型厂商一般会提供HTTP接口或TCP协议。HTTP接口最简单可靠设备识别到车牌后往我们系统的入场接口发一条POST请求系统返回是否抬杆出场时设备再发一条出场请求计费完成后返回放行结果。TCP方式通常需要维护长连接和心跳包代码复杂一些但响应更实时。如果学校实验室没有真实设备可以下载某个免费版的停车场客户端模拟器来代替让模拟器定时推送虚拟车牌数据系统层面的逻辑完全一样。2.4 本地开发环境的目录结构一套标准的单体结构大概长这样。我把代码和SQL脚本分开目录存放方便答辩前重新初始化数据库。parking-system ├── src/main/java │ └── com/example/parking │ ├── controller # 接口控制器 │ ├── service # 业务逻辑 │ ├── mapper # MyBatis数据访问 │ ├── entity # 实体类 │ └── config # 配置类 ├── src/main/resources │ ├── mapper # SQL映射XML │ ├── static # 前端静态资源 │ └── templates # 页面模板 ├── sql │ └── init.sql # 建表语句和初始化数据 └── pom.xml这个结构不复杂但足够支撑后面要讲的所有功能点。接下来进入最关键的数据库设计环节。3. 数据库设计停车场系统的表结构决定计费逻辑能否落地3.1 核心表拆解入场、出场、计费规则分开存很多人喜欢把所有信息塞进一张大表结果出场时状态字段改来改去一条订单记录的入场时间和出场时间写在一起跨天计费和优惠计算全都绕不开状态判断。我的做法是拆成三张核心表入场记录表、出场记录表、计费规则表。入场记录表每来一辆车就插入一条出场时才生成对应的订单记录通过在入场记录表里标记已离场来防止重复计费。计费规则表单独存让管理员可以不改代码就调整收费标准。3.2 车辆入场记录表字段设计与索引设置我把入场记录表的核心字段列出来这是停车系统的地基字段设计必须一次到位。字段名类型说明idbigint主键自增plate_numbervarchar(16)车牌号带汉字entry_timedatetime入场时间entry_imagevarchar(255)入场抓拍图片地址device_idvarchar(32)入口设备编号is_membertinyint是否会员0或1member_idbigint会员ID可空statustinyint0在场1已离场2异常订单exit_order_idbigint关联出场订单ID车牌号字段必须加索引因为车辆入场后再次识别出场时我们要用车牌号去查最近的入场记录。如果不加索引数据量一旦上万出场查询就会明显变慢。status字段建议也加一个普通索引用于后台查询在场车辆列表。3.3 计费规则表按车型和时段设计支持跨天计费规则是整个系统最容易和导师辩论的部分。常见做法是设计成支持按小时计费、按次计费、免费时长、单日封顶四种组合。我采用的规则表结构大致是字段名类型说明rule_idbigint规则IDcar_typevarchar(8)小型车、大型车、新能源free_minutesint免费分钟数unit_pricedecimal(10,2)每小时单价max_daily_chargedecimal(10,2)单日封顶金额is_weekend_difftinyint是否区分工作日和周末weekend_pricedecimal(10,2)周末单价计费逻辑不能只按“总停车时长乘以单价”来做因为跨天停车时单日封顶会导致金额计算复杂化。比如某车停了30小时前24小时按单日封顶算后6小时另算这必须通过规则表来支撑。为了让这套逻辑能跑通建表时还需要补充初始化脚本把常见车型和计费规则预置好。3.4 建表SQL脚本一条可以直接执行的版本下面这个SQL是入场表和计费规则表的实际建表语句已经去掉了冗余字段方便直接复制到Navicat里执行。CREATE TABLE entry_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, plate_number VARCHAR(16) NOT NULL, entry_time DATETIME NOT NULL, entry_image VARCHAR(255), device_id VARCHAR(32), is_member TINYINT DEFAULT 0, member_id BIGINT, status TINYINT DEFAULT 0 COMMENT 0在场 1已离场 2异常, exit_order_id BIGINT, INDEX idx_plate (plate_number), INDEX idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE charge_rule ( rule_id BIGINT PRIMARY KEY AUTO_INCREMENT, car_type VARCHAR(8) NOT NULL, free_minutes INT DEFAULT 15, unit_price DECIMAL(10,2) NOT NULL, max_daily_charge DECIMAL(10,2), is_weekend_diff TINYINT DEFAULT 0, weekend_price DECIMAL(10,2) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO charge_rule (car_type, free_minutes, unit_price, max_daily_charge) VALUES (小型车, 15, 2.00, 20.00), (大型车, 0, 5.00, 50.00), (新能源, 30, 1.50, 15.00);索引和字段注释已经带上了不需要额外说明。启动项目后如果报时区错误在连接URL后面加上serverTimezoneAsia/Shanghai这是本地环境最常见的启动问题。表建好后下一步就是写订单生成的业务逻辑。4. 核心计费逻辑实现订单生成、跨天计费与状态流转4.1 入场接口入场接口的幂等处理设备识别车牌后会请求入场接口如果同一个车牌在一分钟内被请求两次系统不能生成两条入场记录。常见做法是入场前先查同一车牌有没有status为0的在场记录如果有就直接返回到达现有的入场记录。这样既避免了车辆出场时因为重复入场导致的出场混乱也为后面设备的重复回调留好了安全垫。public EntryResult entry(String plateNumber, String deviceId, String imageUrl) { // 先查在场记录防止重复入场 EntryRecord exist entryRecordMapper.findByPlateAndStatus(plateNumber, 0); if (exist ! null) { return EntryResult.alreadyInside(exist); } // 查会员信息是会员则记录会员ID Member member memberMapper.findByPlate(plateNumber); EntryRecord record new EntryRecord(); record.setPlateNumber(plateNumber); record.setEntryTime(new Date()); record.setEntryImage(imageUrl); record.setDeviceId(deviceId); record.setStatus(0); if (member ! null) { record.setIsMember(1); record.setMemberId(member.getId()); } entryRecordMapper.insert(record); return EntryResult.success(record); }这段代码的关键是exist ! null的早返回逻辑。设备回调经常出现重发如果没有这个判断同一辆车会生成多条在场记录出场时辆车会被重复计费。member查询放在入场阶段完成的好处是后续出场结算时不需要再关联会员表查询。4.2 出场计费算法免费时长、单日封顶与跨天出场计费是系统里最需要细抠的算法。我写了一个computeCharge方法传入入场记录和出场时间按照计费规则逐步计算。public BigDecimal computeCharge(EntryRecord entry, Date exitTime, ChargeRule rule) { long totalMinutes (exitTime.getTime() - entry.getEntryTime().getTime()) / 60000; // 先扣除免费时长 long paidMinutes totalMinutes - rule.getFreeMinutes(); if (paidMinutes 0) { return BigDecimal.ZERO; } // 如果规则没有封顶直接按总时长计算 if (rule.getMaxDailyCharge() null) { return rule.getUnitPrice() .multiply(BigDecimal.valueOf(Math.ceil(paidMinutes / 60.0))); } // 有单日封顶时按自然天拆分计算 BigDecimal totalCharge BigDecimal.ZERO; Date cursor entry.getEntryTime(); while (cursor.before(exitTime)) { Date dayEnd endOfDay(cursor); Date segmentEnd dayEnd.before(exitTime) ? dayEnd : exitTime; long segmentMinutes (segmentEnd.getTime() - cursor.getTime()) / 60000; BigDecimal dayCharge rule.getUnitPrice() .multiply(BigDecimal.valueOf(Math.ceil(segmentMinutes / 60.0))); if (dayCharge.compareTo(rule.getMaxDailyCharge()) 0) { dayCharge rule.getMaxDailyCharge(); } totalCharge totalCharge.add(dayCharge); cursor dayEnd; } return totalCharge; }这个算法把每一段的计费单独封顶而不是等累计到总额后再整体封顶。举个例子某车周五晚上10点入场周六中午12点出场收费系统应该按两个自然天的段分别计算如果规则单日封顶20元周五晚上虽然只停了2小时但依然产生费用周六再按当天计算。这才是真实停车场系统的计费逻辑。如果用总时长加整体封顶的错误方法跨天停车会少收很多钱。这段代码里用到的BigDecimal是为了避免浮点金额的精度误差这一点后面在避坑章节还要再提。4.3 出场时更新状态事务控制生成订单和更新入场记录状态必须在一个事务里完成否则可能出现订单生成了但入场记录还是“在场”状态导致车还没出场就能再次触发一次计费。Transactional public ExitResult exit(String plateNumber, String exitDeviceId) { EntryRecord entry entryRecordMapper.findByPlateAndStatus(plateNumber, 0); if (entry null) { // 查不到入场记录走手动入场补充流程 return ExitResult.noEntryRecord(plateNumber); } ChargeRule rule chargeRuleMapper.findByCarType(entry.getCarType()); BigDecimal amount computeCharge(entry, new Date(), rule); // 生成出场订单 ExitOrder order new ExitOrder(); order.setEntryId(entry.getId()); order.setPlateNumber(plateNumber); order.setAmount(amount); order.setExitTime(new Date()); order.setStatus(0); exitOrderMapper.insert(order); // 更新入场记录状态 entry.setStatus(1); entry.setExitOrderId(order.getId()); entryRecordMapper.updateStatusById(entry); return ExitResult.success(amount); }Transactional注解是关键只要后续更新状态抛异常订单也会回滚。很多同学会漏掉这个注解导致数据不一致。这里还涉及一个常见的场景相机识别到了出场车但系统里没有入场记录可能是入场时相机没拍到车牌。我在exit方法中返回noEntryRecord标记前端收到这个标记后展示手动补充入口让操作员先选车牌再计算费用这是答辩评委会追问的功能点。4.4 会员月租车逻辑固定费用和临时计费怎么共存会员车和临时车不能混用一套计费逻辑。月租车入场时不识别为会员按临时车放行出场时也不应该再次自动生成临时费用。我的方案是在入场阶段查出会员后出场时判断isMember字段如果为1且会员状态正常则直接生成金额为0的订单同时记录会员的月租有效期开始时间和到期时间。会员到期当天系统要把isMember标记改为0否则会一直免费出场。这个判断放在入场时并不可靠因为会员可能在车辆在场时过期我选择在出场时重新查一次会员状态以出场时间为准。5. 前端页面与交互设计控制台、入口监测与异常订单处理5.1 页面架构一张控制台页面收拢所有操作前端页面我不建议堆砌一堆二级菜单控制台短链接的设计只需要做到左侧显示当前在场车辆列表顶部显示今日应收金额、月租车数量和异常订单数右侧预留一个手动操作区。它的核心价值是值班员低着头只看一个屏幕就能完成主要操作。技术实现上用Bootstrap加jQuery就够了复杂的前端框架对这个项目是负担。页面展示的车牌号、入场图片、时长这些信息建议服务端通过接口分页返回。5.2 车牌号格式化输入与校验车牌识别一体机识别车牌的准确率并不是100%可靠所以我需要在手动录入时做输入校验。下面是一段车牌号格式化脚本function formatPlate(input) { // 去掉空格和特殊符号统一转大写 let value input.value.replace(/\s/g, ).toUpperCase(); // 简单校验第一位是省份汉字第二位是字母后面是字母数字组合 const provinceChars 京津沪渝冀豫云辽黑湘皖鲁新苏浙赣鄂桂甘晋蒙陕吉闽贵粤青藏川宁琼; if (provinceChars.indexOf(value.charAt(0)) 0) { alert(车牌省份简称不正确); return; } if (!/[A-Z]/.test(value.charAt(1))) { alert(车牌第二位必须是字母); return; } input.value value; }这个校验的价值在于拦截低级手误比如输入“京A12345”和“京a12345”或者输入多了空格导致后台查询不到记录。绿色车牌的新能源车牌是8位字符上述正则已经能覆盖不需要特殊适配。5.3 在进场记录状态轮询与出场按钮场内车辆列表需要每30秒刷新一次避免手动刷新标签页。但轮询有个明显的坑如果页面刷新时恰好有车辆入场后端返回的列表会重新加载正在操作的下拉框或被强制重置。我的解决办法是列表刷新只更新表格区域的HTML不刷新整个页面用fetch请求仅获取列表接口的返回数据。同时把当前选中的车牌号缓存到一个变量中刷新后重建选中状态。这个细节看起来很细但现场值班演示时刚好有车入场导致正在填写的表单被重置就是一场事故。5.4 异常订单手动处理页面异常订单包括无入场记录的车辆、摄像机重复识别导致出场失败、会员过期仍被识别等。单独设置一个异常订单页面状态列表展示异常订单的时间、车牌号、异常类型和备注。操作员可以在页面中为异常订单补充入场时间或调整金额。补充完成后系统会重新计算金额并生成正常的订单。这个页面是答辩时的加分项因为很多同学的毕业设计里根本没有想到异常链路。6. 避坑指南停车场管理系统里最容易翻车的5个细节6.1 车牌号里的汉字被存成乱码现象是入场记录里显示“浣?A12345”数据库字段显示为问号。原因是建表时用了latin1或者连接字符串没有指定utf8mb4。解决方法是统一改所有字符集配置。修改连接URL为jdbc:mysql://localhost:3306/parking?useUnicodetruecharacterEncodingutf8mb4同时表结构已经定义成utf8mb4两个位置不能有一个漏掉。如果已经出现乱码数据需要清掉重录没有后悔药可吃。6.2 出场记录比入场记录多了一条现象是同一辆车出场后订单列表里出现了两条记录金额也重复。原因是出场接口被设备重复回调而我们的代码没有做幂等判断。修复方式是出场接口也要先查status为0的入场记录如果入场记录已经被标记为已离场直接返回原订单信息不再生成新订单。我在4.1小节入场接口做了重复入场过滤但出场接口同样需要处理很多同学只处理了入场却漏了出场。6.3 跨天停车金额明显偏低现象是晚上8点入场、第二天早上8点出场按总时长12小时计费结果只有不到10块钱明显少收。原因是计算时没有按自然天拆分导致单日封顶规则只作用在总时长上。解决方法是使用4.2小节的按自然天遍历算法把每一天的停车时长单独计算再累加。另外要注意的是endOfDay方法要准确返回当天的23:59:59不要用“加上24小时”的写法否则夏令时或毫秒误差会引发边界值异常。6.4 金额浮点运算出现0.30000000000000004现象是金额计算后出现一长串小数。原因是用了double或float来存储和计算金额浮点数的二进制表示天然有精度问题。解决方法是数据库字段用decimalJava实体类用BigDecimal计算时用BigDecimal的multiply和add方法不要用乘法符号。这条规则不仅适用于停车场系统任何涉及钱的系统都应该遵守。6.5 设备网络断连导致车辆一直排队现象是道闸的识别一体机断网后所有车辆在门口排长队系统完全无感知。原因是系统与设备的通信是单向依赖没有做设备心跳检测和离线补偿机制。解决方法是新增一个nvr设备状态表让设备每30秒上报心跳如果系统在2分钟内没有收到心跳就自动将设备状态置为离线并在前端页面用红色标记提示。离线期间尝试入场的车辆可以先放行入场并记录本地缓存等网络恢复后批量提交。这个设计不仅真实而且能给答辩增加不少技术深度。7. 进阶技巧用异步对账机制验证系统数据的准确性停车场管理系统做完基础功能后不要急着提交报告先用对账机制把系统的数据自检一遍。写一个定时任务每5分钟统计一次今日应收金额再和订单表里的sum(amount)对一次不一致就告警。这个自检程序能提前发现很多隐藏的计费问题比如某条订单没计算金额就生成了。定时任务用Spring的Scheduled注解实现核心逻辑就是两条SQL求差值。再把对账结果输出到一个日志文件里答辩时打开日志文件给评委看今天每小时的金额波动曲线比空口介绍系统功能更有说服力。另外还可以做一个更有价值的增强在出场订单生成时记录计费规则的快照。什么意思也就是说订单表里除了保存金额还保存当时使用的单价、免费时长和封顶金额。这样即使后续管理员修改了计费规则历史订单的金额依然有据可查。这个做法看似简单但很多真实的商业系统都忽略了导致对账时出现“规则已改、旧账无法解释”的死局。验收前我也建议做一遍完整流程演练准备两三个车牌号模拟入场、出场、跨天停车、会员过期、无入场记录五种场景确认每一条都符合预期。每晚闭园时段再对一遍当日流水看入场数和出场数是否一致在场车辆数是否等于上一次输出的在场数加本次差额。这是我在那个模拟项目X里踩过坑后养成的习惯——先信代码再做测试代码不会骗人但写代码的人会骗自己。希望这一套从表结构到计费逻辑的笔记能给正在做停车场管理系统的同学省下几个通宵。祝你的答辩一切顺利。本文还有配套的精品资源点击获取