SpringBoot停车场管理系统毕设：数据库设计与计费实现全解析

毕设季又到了每年这个时候我都会收到不少类似的求助选题选了个基于SpringBoot的商场停车场管理系统打开文档发现功能列表写得满满当当真到自己动手写代码时却不知道从哪下手。这个题目乍看简单——不就是车辆进进出出、算个停车费嘛。但真把一个商场停车场跑起来你会发现里面有车辆入场、车位分配、分段计费、跨天结算、月卡会员、车场分区、异常出场处理一堆事。恰恰是这种看起来简单、细想很麻烦的题目做好了是答辩加分项做砸了就是答辩翻车重灾区。这篇文章我打算换个思路不给你贴一个冗长的课程设计说明书而是从这个题目到底考你什么出发把技术选型、数据库设计、核心计费流程、答辩高频追问一次讲透。无论你现在是刚开题还是代码已经写了一部分这篇文章都能帮你把逻辑捋顺。1. 从选题到答辩这个题目的真实难度评估先泼一盆冷水。很多同学选停车场管理系统是觉得它比图书管理系统学生管理系统听起来高级一点又不像电商系统秒杀系统那么复杂。但我要告诉你这个题目的难度恰好卡在中间——比普通CRUD高一些但又不至于让你做不完。关键看你怎么把复杂的部分拆解掉。1.1 为什么停车场是毕设题目的黄金难度一个合格的毕设题目需要同时满足三个条件功能足够多能撑起篇幅、技术点足够典型能覆盖课程所学、数据模型足够清晰能让老师一眼看懂你在做什么。商场停车场管理系统恰好三条全占。往小了做它就是一个车辆信息的增删改查往大了做它能牵扯出车位引导、车牌识别OCR、微信支付、消息推送、大屏可视化这些能写进简历的亮点功能。但这里有个关键建议重业务逻辑轻花哨功能。我见过太多同学一上来就想接真实的车牌识别接口、对接支付宝微信支付结果接口文档还没看完中期检查就挂了。毕设评审老师真正在意的是你能否把业务逻辑梳理清楚、用代码把流程跑通而不是你接了多少第三方服务。从我的经验看这个题目最合适的完成路径是先实现完整的停车计费生命周期再做管理端的数据统计与展示。两步走完工作量、难度、答辩质量都能达到一个不错的平衡点。1.2 一份合格的毕设文档该包含什么提纲是给答辩老师的第一印象跟你代码写得好不好同等重要。我见到的优秀文档一般按这个结构来组织绪论背景、意义、国内外现状、本文工作需求分析功能需求、非功能需求、可行性分析系统设计架构设计、功能模块划分、数据库设计系统实现按模块逐个讲解核心代码逻辑系统测试测试用例、测试过程、结果分析总结与展望不少同学喜欢把大量篇幅花在第一章背景介绍上一个研究意义写三页纸。等到了核心的系统实现部分反而贴几张截图就糊弄过去。这属于典型的舍本逐末。答辩老师翻你的文档重点看你数据库E-R图是否合理、核心功能代码是否讲清楚了、测试用例是否覆盖了边界条件。1.3 工作量怎么划分才不会后期赶工我建议把整个周期按3:4:2:1的比例切分30%时间做需求分析与数据库设计40%时间做编码实现20%时间写文档做测试10%时间留给意外的返工和修改。很多同学死在数据库设计这一步。表结构没想清楚就直接开写写着写着发现字段不够、关系不对回头重构表结构前后端代码跟着一起改改到想哭。所以我会在下一节专门展开讲表结构这是整个项目的地基。2. 技术栈选型为什么是SpringBoot 2.x而不是3.x2.1 技术栈对比与版本选择的底层逻辑考虑到这是毕业设计不是生产环境项目技术选型的原则只有一条成熟、稳、资料多。你踩坑时能在搜索引擎上找到答案比你用了多新的技术重要得多。推荐方案如下后端Spring Boot 2.7.x MyBatis-Plus MySQL 5.7/8.0前端Vue 2 Element UI如果时间紧可用Thymeleaf服务端渲染做一个单体应用权限Spring Security 或 Sa-Token工具Hutool、Lombok、Knife4j接口文档项目管理MavenSpring Boot 3.x虽然已经发布很久但我不太建议毕设阶段用。原因很实际3.x基于Jakarta EE很多网上能找到的教程、配置写法都是基于javax包的你照着老教程写新代码光包名导入就可能报一堆错。对毕设来说能2小时内解决问题就别花4小时研究兼容性。MyBatis-Plus是另一个强烈推荐的组件。它提供BaseMapper单表CRUD基本不用写SQL能把你的开发速度提升一大截。特别是分页、条件构造器这些功能能让代码看起来清爽不少。这里提供一个分页配置的基础写法Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); // 分页插件 interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); // 乐观锁插件用于处理车位并发抢占 interceptor.addInnerInterceptor(new OptimisticLockerInnerInterceptor()); return interceptor; } }2.2 SA-Token还是Spring Security做权限控制时很多同学第一反应就是Spring Security。但Spring Security的学习曲线偏陡配置复杂你很可能花半天时间就为了搞清楚为什么登录成功了但请求还是401。如果你只是想实现管理员登录、拦截未授权请求这个级别的功能我更推荐Sa-Token。它上手快API设计友好登录、鉴权、踢人下线基本都是几行代码的事。最关键的是中文文档做得很好遇到问题能快速定位。这是Sa-Token的登录代码示例简单到几乎没有学习成本RestController RequestMapping(/api/auth) public class AuthController { Autowired private UserService userService; PostMapping(/login) public Result? login(RequestBody LoginDTO dto) { User user userService.login(dto.getUsername(), dto.getPassword()); if (user null) { return Result.fail(用户名或密码错误); } // 登录成功给客户端颁发一个token StpUtil.login(user.getId()); String token StpUtil.getTokenValue(); return Result.ok(token); } }2.3 环境准备过程中最容易被忽略的细节关于IDEA的配置每年都有同学踩坑。项目跑不起来十有八九是JDK版本、Maven仓库、编码格式这几个问题。第一Spring Boot 2.7.x请使用JDK 8或JDK 11不要一上来就配JDK 17。不是说JDK 17跑不了Spring Boot 2.7而是Maven编译和部分插件的兼容性容易出幺蛾子。第二IDEA里把File Encoding全部统一为UTF-8不然中文注释在Windows环境下会乱码。第三Maven建议配阿里云镜像不然首次加载依赖能让你的电脑转圈半小时。下面是一个可以直接复制的Maven阿里云镜像配置放在settings.xml的mirrors节点里mirror idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/central/url /mirror3. 数据库设计一张停车记录表如何支撑整个计费体系数据库设计是整个项目里最考验功底的环节。我的经验是把精力重点放在停车位表和停车记录表的设计上这两张表直接决定你后面所有业务代码怎么写。3.1 商场停车场业务中的核心实体与关系先捋一下商场停车场涉及的实体用户管理员、财务人员、运营人员停车场有些商场有地下B1/B2/B3多层或地面加地下所以要单独建表车位归属某个停车场包含车位编号、所在楼层/区域车辆车牌号、车主信息、车辆类型临时车/月卡车/免费车停车记录一次完整的入场到出场过程计费规则按时段/按次/阶梯计费配置会员卡月卡/年卡/储值卡这些实体之间的关系其实不复杂商场停车场的核心是车位 → 停车场多对一、停车记录 → 车位多对一、停车记录 → 车辆多对一、车辆 → 会员卡多对一。我见过不少同学把车辆和停车记录合并成一张表这是典型的设计失误。因为车辆信息是相对固定的比如车牌、车主手机号、会员类型而停车记录是动态的每进一次场就多一条记录。两张表混在一起要么产生大量冗余要么修改车主信息时把停车历史也污染了。3.2 停车记录表状态字段和金额字段的设计细节停车记录表是业务核心推荐字段如下字段名类型说明idbigint主键record_novarchar(32)订单号格式建议yyyyMMddHHmmss 随机数plate_numbervarchar(20)车牌号space_idbigint车位IDlot_idbigint停车场IDentry_timedatetime入场时间exit_timedatetime出场时间未出场为nullduration_minutesint停车时长分钟出场时计算并回填charge_amountdecimal(10,2)应收金额discount_amountdecimal(10,2)优惠金额paid_amountdecimal(10,2)实收金额statustinyint状态0已入场1待支付2已支付3已离场4异常create_timedatetime创建时间update_timedatetime更新时间MyBatis-Plus的自动填充字段有几点值得你注意金额一律用decimal(10,2)绝不能使用double或float。这一点写论文时可以展开讲答辩老师很爱问。浮点数在计算机中不是精确表示的0.10.2可能等于0.30000000000000004。虽然停车费金额小可能看不出差异但从工程设计角度看涉及钱的字段必须用精确类型。订单号不要用数据库自增ID直接展示给用户。一方面会暴露系统每天的订单量敏感信息另一方面自增ID太容易被遍历猜测。所以单独用一个record_no字段生成规则可以是时间戳随机数。Hutool工具包里有现成的IdUtil工具类两行代码搞定String recordNo IdUtil.getSnowflakeNextIdStr(); // 或者格式化的DateUtil.format(new Date(), yyyyMMddHHmmss) RandomUtil.randomNumbers(4)在入场和出场这两个高频操作中一定要设置唯一索引约束防重。比如同一辆车在同一个时间点只能有一条已入场状态的记录避免用户连续点击二次入场造成脏数据。3.3 计费规则表把算法和数据分离很多同学习惯把计费规则直接硬编码在Java代码里比如if (minutes 30) { amount 0; } else if (minutes 60) { amount 5; }这样写短时间内没问题但一旦商场运营方调整收费标准比如从首小时5元改成首小时6元你就得改代码、重新编译、重新部署。这在毕设答辩中是一个极佳的加分点——把计费规则配置化。方案是设计一张计费规则表字段名类型说明idbigint主键lot_idbigint适用停车场IDrule_namevarchar(64)规则名称如工作日白天标准free_minutesint免费时长分钟base_minutesint基础计费单位如15分钟/30分钟/1小时base_pricedecimal(10,2)基础单价max_daily_pricedecimal(10,2)单日封顶价start_timetime规则生效开始时间end_timetime规则生效结束时间is_holidaytinyint是否节假日规则计费逻辑根据这张表的配置走。这样做的好处是即使你不做一个计费规则管理页面只把表结构和初始SQL放在文档里答辩老师也会认为你有工程意识知道将易变业务规则从代码中解耦出来。这在软件工程课程里对应的是开闭原则——对扩展开放、对修改关闭。4. 停车计费核心流程从入场到出场的完整实现链路这部分是系统的心脏也是答辩时老师最可能让你现场演示或手写思路的地方。你不需要在Demo里真的对接摄像头识别车牌但得把这个流程想明白。4.1 入场流程不是简单的insert一条记录入场逻辑在业务上可以拆分为四个步骤接收车牌号查询车辆是否存在。如果不存在创建一个新车辆自动注册为临时车。查询是否有可用车位。如果有锁定一个车位如果没有返回车位已满。创建一条停车记录状态为已入场。把车位状态改为占用。在这个简单流程里最大的隐患在于高并发下的超卖问题——两个车主同时入场系统只剩下最后一个空车位结果两个人都显示入场成功。虽然毕设Demo里很难触发这种并发场景但这是理论上的必备考量。解决方案有两种。一是用数据库的乐观锁车位表加一个version字段更新时CAS判断版本号一旦更新失败说明车位已被抢占提示用户车位已满。二是给停车记录表加唯一约束比如(plate_number, status)的组合唯一索引保证同一辆车同一时刻只能有一条未出场记录。我用的是乐观锁方案更新车位的SQL大致如下UPDATE parking_space SET status 1, version version 1 WHERE id #{spaceId} AND status 0 AND version #{version}这条SQL执行后影响行数为0说明车位状态已被其他事务修改需要回滚操作并提示车位已满。4.2 出场计费分段阶梯计费的完整案例出场流程最核心的是计算费用。以商场常见的首小时内免费超过1小时按每30分钟2元收费单日封顶30元为例我直接给出一个计算器的实现逻辑public class ChargingCalculator { /** * 计算停车费用 * param entryTime 入场时间 * param exitTime 出场时间 * param rule 计费规则配置 */ public static BigDecimal calculate(LocalDateTime entryTime, LocalDateTime exitTime, ChargingRule rule) { // 1. 计算总停车分钟数 long minutes Duration.between(entryTime, exitTime).toMinutes(); // 2. 先享受免费时长例如30分钟内免费 if (minutes rule.getFreeMinutes()) { return BigDecimal.ZERO; } // 3. 超过免费时长后第一个计费周期怎么算每家商场规则不同。 // 这里以只要超过免费时长即按整段时长计费为例 long chargedMinutes minutes; // 4. 按基础计费单位30分钟向上取整计算 long units (long) Math.ceil((double) chargedMinutes / rule.getBaseMinutes()); BigDecimal baseAmount rule.getBasePrice() .multiply(BigDecimal.valueOf(units)); // 5. 应用单日封顶 if (rule.getMaxDailyPrice() ! null baseAmount.compareTo(rule.getMaxDailyPrice()) 0) { return rule.getMaxDailyPrice(); } return baseAmount; } }这里有几个边界情况需要特别注意也是踩坑高发区跨天停车的分段计费。很多商场的计费规则是当天内封顶30元跨天重新计算。比如你停了25个小时如果简单按720个计费单元算费用远远高于两天的封顶总和。正确的做法是把跨天的记录先拆分成多个自然日区间再按每天的规则分别计算后累加。免费时长在跨天情况下的处理。商场的免费规则通常只是针对首小时或者15分钟内出场免费如果车辆已经停了几天免费时长只在最初入场的那天计算一次不能每天都重新免费一次。大额金额的精度问题。前面提到用BigDecimal这里补充一下计算过程中的取舍——中间步骤不要四舍五入到最后金额展示时才保留两位小数。你如果能在博文或答辩PPT里展示出你考虑到了这些边界条件说服力会远超那些只实现了时间差乘以单价的同学。很多时候毕设的成绩差距不是谁的功能多而是谁把边界想得更全。4.3 后端接口设计RESTful风格与统一响应后端接口建议统一使用RESTful风格不要出现一堆乱七八糟的doXXX方法名。我的接口设计习惯给读者列出来供参考功能请求方式接口路径车辆入场POST/api/records/entry车辆出场POST/api/records/exit查询停车记录GET/api/records?page1size10查询车位状态GET/api/spaces/status生成停车订单POST/api/records/pay统一响应结果集也可以自己封装一层结构如下public class ResultT { private Integer code; // 业务状态码200成功 private String msg; // 提示信息 private T data; // 载荷数据 public static T ResultT ok(T data) { ... } public static T ResultT fail(String msg) { ... } }有了统一ResultController层代码会显得格外干净而且前端处理逻辑也统一了。答辩老师问起你如何保证前后端协作规范时这又是一个可以讲的点。4.4 数据统计模块让系统看起来聪明的加分项纯做入场出场的系统撑死是一座电子台账。真正的商场停车场管理系统一定包含统计报表功能。这个模块做好了你的系统就不只是能用而是好用。我建议至少实现三个统计维度车位利用率某时间段内占用车位数/总车位数。高峰期和低峰期的对比商场运营方非常在意这个数据。收入日报/月报按天/按月汇总实收金额。最好能通过柱状图或折线图展示前端用ECharts就能实现。平均停车时长辅助运营团队判断顾客停留时间与商场的促销活动是否相关。后端统计SQL其实不复杂以查询最近7天每日收入为例SELECT DATE_FORMAT(exit_time, %Y-%m-%d) AS day, SUM(paid_amount) AS total_amount FROM parking_record WHERE exit_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) AND status 2 GROUP BY DATE_FORMAT(exit_time, %Y-%m-%d) ORDER BY day这类聚合查询用MyBatis注解方式写在Mapper接口里即可不一定要用MyBatis-Plus的BaseMapper因为聚合逻辑属于自定义查询还是XML里写SQL更清晰Mapper public interface ParkingRecordMapper extends BaseMapperParkingRecord { ListDailyIncomeVO selectDailyIncome(Param(startDate) String startDate, Param(endDate) String endDate); }统计模块的价值在于它让整个系统有了管理者视角。评审老师看到的不只是能跑而是能用。这在毕设的评分维度里是一个非常加分的观感。5. 答辩高频追问把看起来能用变成经得起问代码写完、文档写完最后一关是答辩。这一节总结我在指导毕业生过程中见过的高频提问以及可以提前准备的回答思路。5.1 关于技术选型的追问与回答思路老师为什么选择SpringBoot而不是Spring MVC回答思路Spring Boot是Spring MVC的封装升级它使用自动配置消除了大量XML配置内置Tomcat项目能以更快的速度启动和部署。从工程化角度看Spring Boot是目前企业级Java开发的主流选择学习和就业衔接更紧密。老师为什么使用MyBatis-Plus但它本质是ORM你对ORM了解多少回答思路ORM解决的是对象和关系型数据库之间的映射问题。MyBatis-Plus在MyBatis基础上提供BaseMapper90%的单表CRUD不需要手写SQL但对复杂业务查询我仍然保留手写SQL的自定义Mapper接口保持可控性和灵活性。老师系统安全性你做了哪些方面回答思路可以从这几个方面说——接口身份鉴权SA-Token的登录拦截、SQL注入防护MyBatis使用预编译#{}参数绑定、密码加密存储MD5加盐或BCrypt、XSS过滤全局过滤器处理请求参数。每一条展开都能压住场子。5.2 关于业务场景的追问与回答思路老师如果高峰期有100辆车同时入场系统会怎么表现回答思路正常表现下系统通过数据库事务和乐观锁控制并发访问同一时刻只能有一个入场事务成功占用一个车位如果100个请求同时进来应用层可以通过线程池和队列进行流量削峰数据库层面依靠索引和唯一约束保证最终一致性。如果有时间可以加一个ReentrantLock或分布式锁来保护核心资源写操作。老师车辆入场后车位被人为占用如何处理回答思路现实中可能出现车位显示空闲但实际被堵住的情况。系统可以设计一个人工上报故障的功能操作员将车位标记为不可用另外出场时如果车牌号和入场时录入不一致可以通过人工审核环节修正并记录异常日志。这个思路体现的是软件设计中人机协同的概念——软件不是替代人而是辅助人做决策。老师如果用户在支付环节断网了订单状态如何处理回答思路订单设计为待支付状态前端发起支付请求后后台会生成支付流水号并定时查询支付结果主动轮询或回调通知。如果用户支付成功但系统未收到结果超时后可以通过补单机制查询第三方支付平台确认。如果张三设计了手动结算和现金支付通道这道题会变得非常好答——直接说明支持现金扫码双通道现金支付由线下核销同步更新订单状态。5.3 项目亮点包装让同一段代码说出不同的价值不少同学做完系统后觉得自己写的都是流水账代码没什么亮点可讲。这里分享一个包装思路把工程化中常见的细节问题转化为系统设计故事。举个例子很多人写订单号会用数据库自增ID你用了雪花算法。这时候不要只说我用雪花算法生成订单号而要说考虑到订单号需要全局唯一、趋势递增且不能暴露业务量我选用了基于时间戳和机器编码的雪花算法在单机环境下也可以通过时间戳加随机数的方式生成业务订单号。这展示了你的设计权衡能力而不只是会调API。再比如停车场的车位状态如果只是在内存中维护系统重启后状态就会丢失。如果你把车位状态硬编码为根据停车记录实时计算那么系统天然具备自恢复能力启动时扫描已入场且无对应空闲车位的记录自动修正车位状态。这个设计讲给答辩老师听立刻就能看出你有分布式系统或高可用系统设计的思维雏形。写在最后两个实际做项目时的建议第一别把所有功能堆在一个项目里。如果这是个人毕设建议拆成两个部分用户端小程序/移动端H5 管理后台Web。用户端面向车主用微信小程序或H5展示车位余量、缴纳停车费管理端面向管理员用VueElement UI做数据管理、统计图表展示。这样拆开的另一个好处是答辩老师问你如何实现前后端分离时你有真实案例可以直接讲而不是照本宣科背定义。第二留出至少一周时间专门打磨测试用例和异常流程。大多数毕设系统只要能跑到正常路径就交付了但答辩老师偏偏爱看异常路径。比如重复扫码入场、车牌输入错误的纠正、车辆未完整出场又再次入场、删除已被引用的车位数据会怎么样。这些场景对应的测试记录写进文档里就是你系统健壮性的最有力证明。我见过太多选题相同的学生有人只做成了带界面版Excel有人却做成了一个小型商业级系统——差距不在于谁用了更炫的技术而在于谁把每个业务细节想清楚、把每一步的前因后果写明白了。希望这篇梳理能帮你把路走稳答辩顺利。