★ FEATURED ARTICLE 停车收费管理系统这个题目可以说是毕业设计圈子里经久不衰的常青树了。几乎每年都能看到一批同学选它源码编号01747这个工程我也带着不少人做过、改过、调过。乍一听就是个停车场收费好像很简单但真正动手做起来里面涉及的技术点相当杂前端页面、后端接口、数据库建模、计费算法、并发场景、报表统计哪一块都能单独拿出来折腾半天。这篇就从头到尾拆一遍这个项目的设计思路和落地过程把技术选型、表结构、计费逻辑、常见坑位一次说透给正在做类似选题或者想拿这个题目练手的同学一个能直接参考的完整脉络。1. 项目整体设计与思路拆解1.1 先想清楚这个系统到底解决什么问题很多人拿到这个题目第一反应是写个增删改查然后一头扎进代码里。但在我来看这是典型的做法最后写出来的东西答辩时一问就露怯。做停车场收费管理系统首先要从业务场景倒推需求一个真实的停车场每天要面对什么车辆进场要记录车牌、进场时间、车位分配。车辆出场要算时长、套费率、收钱、放行。月卡车辆要区分身份不能重复收费。管理员要看今天的流水、本周的收入、每个车位的占用情况。系统要能处理跨天停车、车牌识别失败、重复入场、并发出场这些意外情况。换句话说这个系统的核心不只是收费两个字而是围绕一辆车从进场到出场的完整生命周期把数据记录清楚、把金额算准确、把账目留可查。想明白这一点你在做需求分析和数据库设计时就不会漏东漏西答辩讲业务理解的时候也有话可说。所以我在带着做这个项目时第一件事永远是画业务流程图不是画给老师看而是画给自己看车辆从入场到出场的状态流转、管理员角色的权限边界、计费规则和被计费记录之间的关联。把这些理顺了后面写代码就是填空。1.2 技术选型背后的真实考量这个项目的技术栈我见过各种版本有纯 Servlet JSP 的有 SSM 的也有 Spring Boot 前后端分离的。我的建议很直接能上 Spring Boot 就上 Spring Boot别抱着老框架不撒手。原因有三条第一Spring Boot 天然适合快速交付。毕业设计周期就那么几个月你还要腾时间写论文、做 PPT与其花大量精力在繁琐的 XML 配置和框架整合上不如用 Boot 的自动配置把基础设施一分钟搭好把精力花在业务逻辑上。实际上不少高校的课题本身就要求 Spring Boot提前用也能避免答辩答辩时被问为什么不用主流框架的尴尬。第二前后端分离的架构更贴近工程实际也好展示。前端用 Vue 2 Element UI后端提供 RESTful API配合 Swagger 做接口文档整个演示过程非常流畅。老师问前端怎么和后端交互你可以直接打开 Swagger 页面现场调接口给他看这种所见即所得的演示效果比贴代码强太多。第三生态成熟遇到问题搜得到答案。Spring Boot MyBatis Plus MySQL 这套组合几乎所有报错都能在网上找到解决方案对新手极其友好。哪怕你不熟悉 Plus 的 LambdaQueryWrapper文档也写得足够清楚照着抄就行了。数据库方面MySQL 5.7 或 8.0 都行建议直接上 8.0。Redis 这个阶段可以不加但如果你想让项目有点加分项可以把它用在月卡信息缓存、入场车辆实时计数这些地方量不大技术在答辩时够讲两三分钟是个性价比很高的亮点。2. 核心功能模块与数据库设计2.1 功能模块怎么划分才不重不漏网上能找到的停车场系统源码很多但不少模块划分得很乱车辆管理里塞了收费记录收费记录里又去查月卡信息耦合严重。做这个项目模块边界要清晰我建议按基础数据 → 核心业务 → 运营支撑三层来划分基础数据层系统用户管理、车位信息管理、计费规则管理。核心业务层车辆入场登记、车辆出场结算、月卡办理与续费。运营支撑层停车记录查询、收费流水报表、Dashboard 数据统计。每一层之间是单向依赖的。比如出场结算要读计费规则和车辆进场记录但它不需要关心车位是室内还是室外报表模块只读取停车记录和流水表不直接改业务数据。这种划分方式你在写代码时会发现每个 service 类都很瘦职责清楚后面出 bug 排查也快得多。我自己习惯先写一个功能清单表格把每个模块对应的页面路由、后端接口、数据库表列出来写完再动工。以这个项目为例核心清单长这样功能模块主要接口对应数据表车辆入场POST /parking/entryparking_record车辆出场POST /parking/exitparking_record、payment_record月卡管理CRUD /monthly_cardmonthly_card计费规则设置CRUD /fee_rulefee_rule车位管理CRUD /parking_spaceparking_space流水报表GET /report/revenuepayment_record这张表不仅是开发地图也是你写论文时系统设计章节的现成素材。很多同学临到写论文才开始整理功能其实从一开始就按这个思路记录后面能省两天的功夫。2.2 计费规则设计别把逻辑写死在代码里计费规则是这个项目里最容易做坏的地方。我看到很多初级实现是把每小时5元24小时封顶30元直接写死在 Java 代码里改个价格还要重新编译打包上线之后只能干瞪眼。正确做法是把规则做成数据库表让运营人员可以在界面上配置代码只负责读配置、套规则、算结果。表结构可以参考这样设计规则名称如普通车辆小时费率车辆类型临时车 / 月卡车 / 内部车免费时长分钟比如15分钟内免费单位时长分钟默认60单位价格元单日封顶金额元0表示不封顶跨天策略按自然日分段计费 / 按连续时长计费生效起止时间这里面最容易忽略的是跨天策略。一辆车停了两天究竟是按实际总时长套一个费率算总价还是每天分别计算再累加两种算法结果可能差很多。我见过不少项目在这个问题上翻车原因很简单——测试数据都是当天进当天出根本覆盖不到跨天场景。你在设计方案时就要明确这一点并且在答辩时能讲出为什么这么选按自然日分段更接近停车场实际运营习惯因为每天凌晨不少停车场会重新计费或按天封顶结算。再说一个细节免费时长的判断。15分钟内免费是指进场到出场不到15分钟就收0元这个逻辑本身很简单但要注意毫秒级的边界问题。假设免费时长设定为15分钟车辆停了14分59秒和15分00秒结果完全不同。计算时长时最好统一用分钟差向上取整或者向下取整的规则并把这个规则在代码注释里写明否则测试时容易出现0元和5元只差一秒的争议。3. 数据库设计与核心流程实现3.1 关键表结构的设计要点数据库表的设计直接决定后面写代码的顺畅程度。这个项目我建议至少建六张表系统用户表、车辆信息表可选用于绑定固定车、停车记录表、支付流水表、计费规则表、月卡表。其中最重要的就是停车记录表它是整个业务的主线。停车记录表的核心字段包括主键 ID车牌号入场时间出场时间车辆类型临时 / 月卡停车时长秒或分钟应收金额实收金额计费规则 ID快照方式记录当时规则入场操作人出场操作人状态入场中 / 已出场 / 异常这里面有两个非常关键的设计点值得单独说一下。一个是计费规则 ID 要冗余到停车记录里。为什么要冗余因为计费规则表是可以被修改的如果出场结算时再去实时查规则表万一管理人员在车辆停着期间调整了费率出场时是按新费率还是旧费率算这会产生纠纷。把进场时适用的规则 ID 和费率快照存到停车记录里出场时直接用它计算就能保证同一辆车从进场到出场整个过程中的计费口径始终一致这在真实停车场业务中是基本要求。另一个是金额字段要存分为单位整数而不是直接用 double 存元。这个习惯可能很多刚开始做项目的同学不理解认为元更直观。但在 Java 里用浮点数做金额运算会出现0.01元误差累积的问题比如1.50元乘个系数结果变成1.4999999。用整数分做存储界面显示时再转换为元既避免精度问题面试时讲出来也显得你懂工程实践规范。3.2 车辆进出的核心流程时序一辆车进场的流程看起来简单但实现时每个环节都有对应的状态变更入场时先根据车牌号查月卡表判断车辆身份如果是临时车生成停车记录状态设为入场中占用一个空闲车位如果是月卡车同样生成记录但标记为月卡计费如果车位已满给出提示不允许入场。出场时根据车牌号找当前状态为入场中的记录带上入场时间、车辆类型、计费规则计算停车时长和金额生成或更新支付流水把停车记录状态改为已出场释放车位。整个过程需要保证在同一事务里完成否则可能出现钱收了但状态没改的脏数据。这里面有一个并发问题值得注意同一辆车可能几乎同时被两个出口扫描到出场。这在大流量停车场不常见但演示答辩时完全可能发生——老师手动刷新页面连续点两次或者浏览器开了两个标签页操作。解决办法很简单出场接口的核心逻辑里先对车牌或记录 ID 做状态比对 更新操作保证只有状态是入场中的记录才能被结算已经结算过的直接返回该车辆已出场。用通俗的话说就是要加一道防重复提交的保险否则账目会乱。说到计费算法的实现可以用一个简单的伪代码逻辑来梳理从停车记录拿入场时间当前时间作为出场时间。计算总时长分钟。如果小于免费时长金额为0。如果车辆类型是月卡且月卡有效金额为0直接放行。临时车按规则表配置先算单位时长数量向上取整不满一个计费单位按一个单位算然后乘以单位价格。如果存在单日封顶且总金额超过封顶值按封顶值收取。跨天停车先按策略拆分区间再对每个区间分别套用上述逻辑最后累加。这套逻辑看起来不难但真正写的时候跨天拆分和向上取整的边界条件是最容易出 bug 的。我的习惯是写一个独立的方法来计算费用所有规则参数都从这个方法入参传进去不直接访问数据库。这样既方便单元测试也可以在答辩时演示我写过测试用例覆盖这些边界情况。4. 实操过程与关键环节落地4.1 环境准备与项目初始化实际操作层面先把环境确认好JDK 8 或 11MySQL 8.0Maven 3.6 以上。Spring Boot 版本建议 2.7.x不要一上来就上 3.x因为很多教程和现成代码还是基于 2.x 写的版本不匹配带来的依赖坑对新手来说很致命。项目初始化时我用 Spring Initializr 生成基础骨架依赖只选 Web、MyBatis Framework、MySQL Driver、Lombok。别贪多B 站教程里那些花里胡哨的依赖等有需要再加。前端部分用 Vue CLI 创建一个 Vue 2 工程安装 Element UI 和 axios路由用 vue-router。启动项目的顺序也有讲究先启动 MySQL 并执行你写好的建库建表脚本再启动后端最后启动前端。后端启动成功的标志是日志里出现 Tomcat started on port前端则是 npm run serve 之后浏览器能打开登录页。我遇到过不少同学卡在数据库连接失败这一步排查下来十有八九是 MySQL 的账号密码、端口跟 application.yml 里配置的不一致或者是 MySQL 8 的驱动包版本太老导致认证方式不兼容。提前确认 mysql-connector-java 的版本和 MySQL 服务版本匹配能省掉大量无意义的折腾。4.2 计费接口与前端页面怎么配合核心计费接口按 RESTful 风格设计这里给一个出场结算接口的典型实现思路POST /api/parking/exit 请求参数车牌号 plateNo 处理流程查停车记录 - 判状态 - 算金额 - 生成流水 - 改状态 - 释放车位 返回结果车牌号、入场时间、出场时间、停车时长、应收金额前端页面就调用这个接口拿到金额后弹窗展示给管理员确认点击确认收费后再真正提交。注意这里我建议预结算和确认结算两步分开而不是点一下就全部完成。原因有两个一是给操作人员一个确认环节避免误操作。真实场景里管理员要跟车主确认金额如果接口直接结算完了就来不及改。二是这个交互方式在演示时更好看——先展示明细再点击确认每一步都有反馈答辩时老师能清晰看到数据流转。前端页面上还有几个体验细节值得做车牌号输入框要大、支持中文最好自动转大写出场页要能显示参考金额和停车时长减少管理员心算压力收费成功后给出明显的成功提示并支持打印小票可以做成一个简单的弹窗页面用浏览器打印功能实现。这些小功能代码量不大但会让整个系统看起来完成度很高在评分时很加分。4.3 报表统计的落地技巧报表模块往往是同学最后才做、也是最容易草草了事的部分。但报表做得好整个项目的成色立刻不一样。核心的报表需求其实就三个今日收费汇总、近7天/30天收费趋势、当前车位占用情况。收费汇总就是一个 SQL 聚合按天分组、求和、计数。趋势图用前端图表库如 ECharts展示接口返回的日期和金额数组。车位占用情况则根据停车记录状态和车位表的状态字段算出来。这里有个小技巧所有报表接口都建议在后端单独写一个统计查询别复用列表查询接口再在前端做聚合。因为列表接口通常做了分页数据不全聚合结果自然是错的。很多同学在这里踩坑——页面上显示的数字和数据库里实际流水对不上一查发现是前端只对当前页做了求和这种问题非常典型答辩时被问一下就很尴尬。5. 常见问题与排查技巧实录5.1 典型问题速查表这个项目做下来我整理过一份高频问题清单基本覆盖了同学找我排查的绝大部分情况。症状可能原因排查/解决思路后端启动报数据库连接失败MySQL 服务未启动 / 账号密码错误 / 驱动版本不匹配确认 MySQL 服务状态核对 application.yml 配置更换 mysql-connector-java 版本前端请求后端接口报 404网关路径 / 端口不一致或 Spring Boot 项目名带 context-path检查 axios 的 baseURL确认接口路径和 Controller 上的 RequestMapping 完全一致接口返回 401 或 403登录拦截器 / 权限校验未放行该接口查看拦截器配置把登录和静态资源路径加入放行名单车辆重复出场结算成功出场接口缺少状态校验在结算前判断记录状态必须是入场中才允许结算计费金额和手算不一致时长取整规则或跨天计算逻辑有误用固定入参写单元测试覆盖免费时长、整小时边界、跨天三类数据报表金额和流水对不上前端对当前页做了聚合或统计 SQL 缺少条件统计逻辑全部放后端明确过滤条件如状态、支付时间范围这张表建议你直接存一份遇到问题先对照看一圈再深入调试。因为大多数问题都是配置类、条件类问题不是算法问题。5.2 几个值得记下的避坑心得第一关于金额精度。前面说过用分为单位存储这里补充一点数据库表字段类型用 INT 或 BIGINT 都行但千万别用 VARCHAR。字符串存数字做聚合运算时要反复类型转换报表性能也会受影响。第二关于时间处理。项目的所有时间字段统一用 Java 8 的 LocalDateTime不要用 java.util.Date。LocalDateTime 配合 MyBatis Plus 的自动填充功能insert 时自动填创建时间、update 时自动填修改时间可以省掉大量重复代码。比较时间区间时注意时区问题本地开发和服务器可能出现 8 小时差遇到时间显示不对先排查时区配置。第三关于演示数据。答辩之前一定要准备一组有故事性的演示数据一辆停了一个小时整的临时车、一辆停了 14 分钟的免费车、一辆停了两天的跨天车、一张即将过期的月卡。用这组数据现场走一遍流程比临时随便录几辆车效果强得多。我甚至见过有同学提前把某个车位改成已占用演示车位管理的时候现场释放比干巴巴地展示列表生动很多。第四关于代码注释和命名。答辩时老师会翻代码变量命名是 a、b、c 还是 plateNo、parkingRecord印象分完全不一样。不用写长篇大论注释但关键方法上面两三行说明这个方法做什么、入参出参是什么以及计费算法里注明取整和封顶规则就足够了。结尾的几句实在话停车场收费管理系统这个题目做完一遍你会发现它真正锻炼的不是写业务代码的能力而是把一个场景抽象成系统的能力。从需求分析到表结构设计从计费规则到报表统计每一环都在逼你想清楚数据从哪里来、到哪里去、中间经过什么规则。带过的同学里凡是把这个项目从头到尾独立做完、并且能讲清楚每个设计决策的毕业答辩基本都很稳。最后再分享一个小经验如果你时间充裕试着往项目里加一个车牌号模糊匹配查找的小功能用 MyBatis Plus 的 LambdaQueryWrapper 做一下模糊查询再去研究一下怎么给它加索引。这个点虽然小但足够在答辩时体现你对数据库性能优化的理解属于性价比很高的一笔投资。
阅读完成 · 觉得有帮助？
