基于Spring Boot与Vue的智能停车场车位租赁管理系统实战

1. 项目背景与需求拆解1.1 智能停车场车位租赁管理系统到底解决什么问题先聊一个现实场景很多城市写字楼、老旧小区、医院周边的停车场白天大量车位空置晚上周边居民却找不到地方停车。传统的停车场管理系统基本只做“进场-计费-出场”按小时收费车位属于谁、是否被长租、哪个时段空闲系统一概不管。于是出现了两类典型矛盾一是物业想提高车位周转率增加营收但车位信息不透明租赁流程靠手写台账经常出现“交了钱没车位”“车位被重复租”的情况二是车主想按周、按月、按固定时段租一个稳定车位但要么找不到渠道要么只能找物业打听。某停车场运营公司曾做过统计单纯临时计费模式下工作日晚间车位利用率不到40%改为“临时长租时段租赁”混合模式后整体利用率能提升到70%以上。我去年参与开发了一个基于Spring Boot Vue的智能停车场车位租赁管理系统核心目标就是把车位的“临时停车”和“预约租赁”整合到一个平台里。系统支持车位主和管理员发布车位、设置可租时段和价格车主在手机端或Web端浏览空闲车位、按小时/天/月下单租赁在线支付后获得指定时段的使用权车牌识别设备对租赁车辆自动放行。这里要特别说明很多人以为车位租赁就是“月卡管理”其实真正的租赁系统要比月卡复杂得多它涉及错峰共享、时段重叠校验、费用自动结算、违约处理以及和设备闸机的联动这些都是普通计费系统不具备的能力。这个系统适合谁来参考如果你正准备做一个类似的停车管理项目或者想了解Spring Boot Vue全栈项目的业务建模思路这篇内容都能给你一个完整参考。我会从需求拆解、表结构设计、核心接口实现、前端页面开发到部署优化把所有关键环节讲清楚。1.2 技术选型背后的逻辑为什么是Spring Boot和Vue项目立项时团队内部其实讨论过要不要用微服务甚至有人提议用Python的FastAPI。最后统一下来的方案是Spring Boot 2.7 Vue 3 MySQL 8原因很实在第一Spring Boot生态最稳妥。停车场业务涉及订单、支付、权限、报表相关组件MyBatis-Plus、Spring Security、Redis、定时任务都非常成熟文档多问题累积少团队里几乎所有后端开发都能直接上手。更关键的是Spring Boot的自动配置特性让项目初始化成本极低我们可以在一天之内把基础框架搭建完把精力留给业务逻辑而不是环境配置。第二Vue 3是国内中小企业管理系统前端的主流选择。配合Element Plus组件库后台管理界面和用户端的停车大屏都能复用同一套组件体系。相比ReactVue的模板语法更接近传统HTML团队里偏后端的同事也能快速上手改页面这对小团队来说非常重要。第三项目的核心是“租赁业务”而不是高并发实时处理。如果要做那种全城停车场秒级计费的平台可能需要考虑更复杂的分布式事务和消息队列但我们的目标是单停车场、多出入口的租赁管理状态并发量在百级别MySQL Redis完全够用不需要为了技术炫技而引入不必要的复杂度。2. 系统架构与模块设计2.1 整体架构与核心数据流这个系统从使用角色上分为三类管理员物业/后台运营方、车场端操作员岗亭收费员、车主/租户普通用户。从终端上分为三个端管理后台Web端Vue管理界面、用户小程序/Web端这里我们先用Vue实现H5适配、后端服务端Spring Boot提供REST API。先画一下整体的数据流从用户发起租赁到最终完成的路径用户在小程序/H5端浏览车位的实时状态空闲、已租、故障看到某个空闲车位后提交预约订单选择租赁开始时间和结束时间系统在提交订单时先执行一次可用性校验锁车位状态订单创建成功进入待支付状态用户支付后支付平台回调后端后端确认支付成功、更新订单状态并生成车位的租赁记录同时把车位标记为“已预定”如果用户还没进场则可以保留一段时间等车辆进场识别通过后系统将车位状态变为“使用中”。租赁到期前系统发送提醒到期后如果用户不续租车位自动释放回空闲状态。这套数据流里最容易出错的是“车位状态和订单状态不一致”。比如用户支付成功后车位没有变成已预定或者用户超时未进场车位没有释放都会导致线下混乱。所以设计时我们专门引入了一张“车位状态变更流水表”来解决这个问题所有车位的状态变化必须经过流水记录不能直接UPDATE一下了事方便追溯。2.2 核心功能模块划分按照业务边界系统拆成了九个模块用户认证与权限管理登录、注册、JWT签发、菜单权限、按钮权限后台用户和车主用户分开管理。车位信息管理车位编号、区域、楼层、类型普通/新能源/无障碍、绑定车牌、计费模板。租赁套餐管理按时段计费例如白天8:00-20:00、按天计费、按月包租以及非工作日特殊定价。订单中心预约订单的创建、支付、取消、退款、续租、订单状态机管理。支付与结算接入第三方支付平台模拟或真实处理支付回调、退款、对账。车辆进场与出场调用车牌识别设备接口联动车位状态生成进出场记录。消息通知订单到期提醒、车位释放通知、支付成功通知。数据统计营收统计、车位利用率统计、订单量趋势、租赁时段热度分析。系统配置停车场基本信息、计费规则、运营参数自动释放时间、预约保留时长。每个模块的边界尽量单一。开发时按模块分人负责接口定义先约定好这样可以保证并行开发不冲突。2.3 角色权限体系我见过很多管理后台权限设计混乱连“运营人员能不能查看营收”都说不清。这个系统我用RBAC基于角色的访问控制模型表结构是标准的五张表用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。管理员这个角色内部又细分超级管理员拥有全部权限可以配置计费规则、查看财务报表运营人员可以管理车位、处理订单、查看统计操作员只能处理进出场、查看车位实时状态不能修改价格。车主用户角色独立于后台用户体系但为了复用登录逻辑我让他也走同一套用户表只是一个字段区分用户类型。有一点值得提醒前端页面上的按钮要根据权限动态控制“新增租赁套餐”“退款审批”等操作否则运营人员看到按钮点了却报403体验很差。后端的接口必须再做一次权限校验前端隐藏只是体验优化不是安全措施。3. 数据库设计动手环节3.1 车位信息与状态表设计数据库设计决定了这个项目一半的成败。我第一个建议是不要试图把所有业务塞进一张大表宁可多几张关联表也不要让字段爆炸。车位核心表parking_lot和parking_spaceparking_lot停车场id、名称、地址、总车位数量、经度、纬度、营业时间、状态。parking_space车位id、lot_id、space_number车位编号、area/楼层区域、space_type1普通 2新能源 3无障碍、status0空闲 1已预定 2使用中 3故障 4锁定、charge_template_id、create_time、update_time。这里status是高频更新字段会出现并发问题所以后面我加了一个version字段做乐观锁确保多人同时预订同一个车位时只有一个能成功。另外车位信息里一定要加一个is_deleted逻辑删除字段但注意不要和物理删除混淆。重要的是车位不是简单的新增字段。每个车位可以关联一种计费模板也可以单独设置时段价格。例如B1区普通车位是月租固定价B2区新能源车位支持按时计费。所以我把价格策略单独做成charge_template和charge_template_detail表模板主表存模板名称、适用对象、计费类型按时/按天/按月明细表存起止时段、单价、是否工作日生效。3.2 租赁订单与支付流水表租赁订单表是业务的中枢字段很多挑关键的说rent_orderid、order_no业务单号、user_id、space_id、lot_id、start_time、end_time、duration_type1小时 2天 3月、total_amount、pay_status0未支付 1已支付 2已退款 3部分退款、order_status1待支付 2支付成功待进场 3已进场使用中 4已完成 5已取消 6已过期、car_number绑定车牌、create_time、pay_time、cancel_reason。这里有个关键约束同一个人同一时间段只能对一个车位发起有效订单避免用户自己重复下单。所以我在user_id start_time end_time order_status上做了联合唯一索引的组合约束限制住状态“待支付/已支付/使用中”时不允许重复。数据库层面约束比代码判断可靠得多。支付流水表pay_transactionid、order_id、payment_type1微信 2支付宝 3余额、transaction_no第三方流水号、amount、status0发起 1成功 2失败 3退款、notify_data回调原始数据、create_time。支付流水必须独立于订单因为一次订单可能有多条支付流水例如先付部分定金、尾款补缴、退款如果只放在订单表里回溯对账会非常痛苦。3.3 用户、会员与管理员表设计用户表sys_userid、username、passwordBCrypt加密、phone、nickname、user_type1管理员 2车主、wx_openid可选、status、create_time。注意密码绝对不能明文存储即使是内部系统也不行我用BCryptPasswordEncoder。因为是租赁系统用户可能需要开通会员享受折扣所以我额外设计了一个member_level的概念普通用户、银卡会员9.5折、金卡会员9折、企业客户协议价。会员等级和用户表分离放user_member表id、user_id、level、expire_time、discount_rate。这样避免用户表字段过多会员权益也能灵活扩展。车位主如果还需要管理“我的车位出租收益”那可以单独建一个space_owner表把车位归属关系和分润比例存进去。我们第一版没做车主C2C出租只做了平台统一运营所以这个表暂不放但如果你要做共享停车位模式一定要提前规划好车位归属人本次会话不能分享存成字段就行。4. 后端接口与核心业务实现4.1 项目初始化与依赖清单项目使用Spring Boot 2.7.18目的是在JDK 8和JDK 11下都能稳定运行。核心依赖如下dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId /dependencyMyBatis-Plus让我省掉了大量单表CRUD的XML代码生成器把实体、Mapper、Service一次性生成出来后面只需要关心复杂业务SQL。Redis用来做车位状态缓存和分布式锁后面会具体说。4.2 车位状态流转的关键实现车位状态机是这个系统的核心。简单说车位从“空闲”到“已租赁”再回到“空闲”的过程不能随意跳跃。我在Service层统一通过changeSpaceStatus(spaceId, fromStatus, toStatus, orderId)方法操作不允许Mapper直接UPDATE状态。我的状态流转约束是这样的空闲(0) → 已预定(1)用户成功下单并支付后已预定(1) → 使用中(2)车辆进场识别使用中(2) → 空闲(0)租赁到期后释放或用户提前离场已预定(1) → 空闲(0)超时未进场、用户取消、后台驳回已预定(1) / 使用中(2) → 故障(3)设备报障或管理员锁定具体到代码里我会给parking_space表加一个version字段在更新状态时使用乐观锁Update(UPDATE parking_space SET status#{newStatus}, versionversion1, update_timeNOW() WHERE id#{spaceId} AND status#{oldStatus} AND version#{version}) int updateSpaceStatus(Param(spaceId) Long spaceId, Param(oldStatus) Integer oldStatus, Param(newStatus) Integer newStatus, Param(version) Integer version);执行时先查出版本号再执行更新如果影响行数为0说明其他请求已经改了状态当前操作失败要提示用户“车位已被预订”。这套逻辑用代码写出来很简单真正复杂的在于“释放时机”。比如一个用户租了今天18点到21点的车位他在1800之前已经进场了系统不能因为没到18点就不让进所以进场判断需要比较start_time和当前时间允许提前最多30分钟进场超过则提示“未到进场时间”。4.3 租赁费用计算与优惠规则处理计费不能直接简单写个乘法。需求里有很多“坑”包月、包周、夜间时段、工作日/节假日、首小时优惠、跨天计费、会员折扣。第一版实现里你如果只用一个单价字段后面改规则会改到怀疑人生。我的做法是计费模板详情表里存储分段规则每个规则有起始时间、结束时间、单价、类型。费用计算时取出模板详情按时间顺序判断所属时段累加费用。例如某个车位模板是“工作日白天8:00-20:005元/小时非工作日全天3元/小时”那计算逻辑就是public BigDecimal calculateAmount(ChargeTemplate template, LocalDateTime start, LocalDateTime end) { ListChargeTemplateDetail details template.getDetails(); BigDecimal total BigDecimal.ZERO; LocalDateTime cursor start; while (cursor.isBefore(end)) { // 找到 cursor 时刻适用的计费规则 ChargeTemplateDetail detail getMatchedDetail(details, cursor); // 计算当前规则下最小时间片 LocalDateTime nextCursor getNextBoundary(cursor, end, detail); long hours Duration.between(cursor, nextCursor).toHours(); if (Duration.between(cursor, nextCursor).toMinutes() % 60 ! 0) { hours 1; // 不足一小时按一小时算规则里要写明 } total total.add(detail.getPrice().multiply(BigDecimal.valueOf(hours))); cursor nextCursor; } return total; }注意几个细节不足一小时按一小时计费要提前和业务确认有些停车场按分钟计费跨天时如果模板里配置了“封顶价”一天内最高收费30元需要在每次累加后判断是否超过封顶价。我用BigDecimal计算金额不用double这是金融计算的常识。会员折扣放在订单总金额计算之后但必须在支付前计算好discount_amount字段存下来而且折扣规则要快照。因为用户下个月可能升级了会员订单金额不能跟着变化。我建议在rent_order表里冗余一个discount_rate字段把下单那一刻的折扣率记录下来。4.4 支付回调与订单超时处理支付环节我们对接的是模拟支付网关便于开发测试但生产环境回调逻辑是类似的。关键点在于支付回调是异步的网络可能重复通知处理必须幂等。我在pay_transaction表设置transaction_no唯一索引回调处理时先执行INSERT ON DUPLICATE KEY UPDATE再判断是否已经处理过如果该流水号已存在且状态为成功直接返回成功。接着业务处理如下public void handlePayNotify(PayNotifyDTO notify) { // 1.校验签名 if (!payService.verifySign(notify)) throw new BusinessException(签名验证失败); // 2.查流水 PayTransaction tx payTransactionMapper.selectByTransactionNo(notify.getTransactionNo()); if (tx ! null SUCCESS.equals(tx.getStatus())) { return; // 已经处理幂等返回 } // 3.更新流水状态 tx.setStatus(SUCCESS); payTransactionMapper.updateById(tx); // 4.更新订单状态 RentOrder order rentOrderMapper.selectById(tx.getOrderId()); order.setPayStatus(1); order.setOrderStatus(2); order.setPayTime(LocalDateTime.now()); rentOrderMapper.updateById(order); // 5.车位状态设为已预定 parkingSpaceService.changeSpaceStatus(order.getSpaceId(), 0, 1, order.getId()); }订单超时关闭放在Redis里处理。创建订单时设置一个带过期时间的Key例如order:expire:${orderNo}过期时间30分钟。用Redis Key过期事件订阅监听到后判断订单是否仍然待支付如果是则把订单状态改为“已取消”车位释放为空闲。这里要注意Redis过期事件默认不保证100%及时如果业务要求强一致需要配合定时任务扫表补偿。我们用了Spring的Scheduled定时任务每分钟扫描一次待支付超过30分钟的订单做兜底关闭双保险。5. Vue前端实现要点5.1 Vue3 Element Plus 工程搭建前端我用Vite Vue 3 TypeScript Pinia Vue Router Element Plus。Vite启动快HMR体验好。工程结构上我按功能而不是按类型来分目录src/api/所有接口请求定义src/views/页面级组件比如停车大屏、车位管理、订单管理src/components/通用组件比如车位格子、订单卡片src/stores/Pinia状态管理区分用户状态、车位状态、订单状态接口请求统一封装在request.ts里基于Axios。拦截器里做两件事请求拦截器从localStorage里取JWT Token放到Authorization头响应拦截器统一处理401跳转登录、401以外提示后端返回的错误消息。这里有个经验后端返回结构建议统一为{code: 0, data: ..., message: 成功}前端不用每次判断HTTP 200以外的情况逻辑统一很多。5.2 停车场实时状态大屏怎么做运营方入场第一眼看到的就是停车场的实时状态大屏。页面核心是左边统计卡片中间是车位分布图右边是今日订单动态列表。车位分布图我用CSS Grid实现不需要地图引擎。每个车位一个div不同的status对应不同颜色绿色空闲、蓝色已预定、红色使用中、灰色故障。点击车位会弹出侧边栏显示该车位详情和当前订单信息。车位状态从哪来两种方案一是短轮询每5秒请求一次/api/space/status简单直接二是WebSocket推送实现更优雅但需要维护连接状态。第一版我用了短轮询实测每个管理员最多同时看一个屏幕5秒一次对后端压力完全没问题。后来人多了一点就改成了WebSocket后端定时推送全部车位状态快照前端全屏刷新。WebSocket通道建立一个线程推送列表每次推全量60个车位也就十几KB带宽成本很低。页面里还要展示“剩余可用车位”的数量这是根据统计查询实时算的。SQL不要用COUNT WHERE status0频繁跑数据量大后效率不行。我们在Redis里维护一个space:available:${lotId}计数器每次状态变更时同步增减。大屏直接读Redis数值性能非常稳。5.3 车位租赁表单与操作逻辑车主端H5页面里最重要的交互是“选择车位-选择时间-提交订单-支付”。这里有几个容易踩坑的设计点时间选择器要禁用已不可用的时间段。实现方式不是前端写死而是后端在用户点击车位后返回一个availableTimeSlots字段里面是当前车位已被占用的时间区间数组。前端用Element Plus的disabled-date函数把这些区间标记为不可选。提交订单前建议做二次确认页展示费用明细按时长价格、会员折扣、总价。用户点击“确认支付”后后端才真正创建订单前端拿到orderNo跳转支付。如果订单创建成功但用户未支付页面要显示倒计时剩余支付时间超时后端会关闭订单。这个倒计时不要死守在本地前端应该从后端获取该订单的expire_time本地做差值计算避免刷新后时间错乱。6. 实际开发中踩过的坑与排查记录6.1 并发抢车位时还是出现了超卖上线后第一次做抢车位活动同一时间很多人抢同一个热门车位。即使我们在JVM代码里先查状态再更新仍然出现两个订单都支付成功了。原因是两个请求同时查到状态为空闲都执行了更新但MyBatis-Plus默认更新时没有带version旧值。排查时通过日志发现是更新语句被优化为只根据id更新根本没带状态条件。修正方法有两步一是使用我前面展示的乐观锁SQL强制判断status0二是在代码中加Redis分布式锁锁的Key设计为space:lock:${spaceId}在创建订单和变更车位状态时先锁住操作完成再释放。RedisTemplate的锁要注意设置过期时间防止业务异常导致死锁。我用setIfAbsent(key, value, Duration.ofSeconds(10))拿锁释放前先判断value是否是自己写入的防止误删其他线程的锁。6.2 运营商后台显示的车位状态和用户端不一致当时用户端App显示B-023车位空闲但管理后台显示已经是“使用中”。原因是用户端和后端管理端各用了不同的缓存Key前端把车位状态改写进了localStorage后台从数据库查询两边数据不一致。彻底解决方式是统一以Redis缓存为唯一状态源任何客户端查询都走后端接口前端本地不持久化车位状态。缓存更新时机是有人下单成功、支付回调成功、进场识别成功、退场释放这四个节点都必须通知Redis更新对应Key。后来还在缓存里加了space_status_last_update时间戳字段便于排查问题。6.3 支付回调重复通知导致订单重复处理有一次压测模拟支付平台发送多次回调由于处理逻辑里没有先查流水状态导致订单状态从“支付成功”被改回“待进场”并且车位状态异常。修复后我提高了幂等判断的优先级一切以支付流水表为准。先插入流水若插入冲突说明是重复通知直接返回然后才更新订单。为了避免网络延迟导致的回调顺序错误又在更新订单时加了WHERE order_status待支付条件保证只有待支付订单才能接收支付成功通知。6.4 前端按钮权限漏控制刚上线时普通运营人员可以看到“删除用户”按钮点击后提示无权限虽然数据安全没出问题但体验很差。我的整改方案是在路由配置里增加meta: { permissions: [system:user:delete] }前端在渲染按钮时通过v-if判断当前用户角色所包含的权限标识没有权限直接不显示。后端仍然校验接口权限双管齐下。这里要强调前端权限只是体验后端接口权限才是安全底线。6.5 定时任务扫表时锁冲突关单定时任务用SELECT ... FOR UPDATE扫待支付订单导致用户正在支付时支付回调更新订单却被锁阻塞。我后来把定时任务改造为只扫描“创建时间超过30分钟且状态为待支付”的订单扫描量很小不至于锁范围过大。同时把订单关闭操作放到独立线程池和支付回调处理通过Redis锁竞争同一订单时也能保证顺序。7. 部署上线与性能优化建议7.1 打包与部署的几个小细节后端用Maven打Jar包注意排除掉本地环境配置文件通过--spring.profiles.activeprod加载生产配置。生产环境里我把MySQL和Redis单独部署不和应用挤在一台机器上避免资源竞争。采用Nginx作为反向代理前端build后把静态资源放到/usr/share/nginx/html配置location /api/转发到后端服务解决跨域问题。启动后第一件事是检查SQL连接池参数。默认的HikariCP最大连接数10对生产可能有点紧张我调到maximum-pool-size: 50并设置了connection-timeout: 3000ms避免请求排队太久。另外MySQL的max_allowed_packet调大了一些应对大量写入。有一个细节容易被忽略Spring Boot应用启动时会初始化定时任务如果两台机器同时启动定时任务会重复执行。我用了简单方案只选一台作为定时任务执行机通过配置项task.scheduler.enabled控制。更可靠的是接入分布式任务调度框架但对这个项目来说没必要。7.2 核心性能优化手段系统日常并发不高但有几处写入频繁优化后效果明显车位状态更新缓存读操作全部走Redis数据库只在状态变更时写一次。Redis宕机时降级为直接查询数据库保证业务可用。订单查询分页优化订单表数据增长快针对user_id和create_time建立联合索引列表页默认按时间倒序并限定最近三个月避免深度分页回表查询过多。报表统计走独立只读库我们开启了MySQL主从复制统计模块的查询走从库不影响主库写入性能。没有主从的话可以先把统计数据异步计算好存到统计表避免实时聚合。车牌识别接口调用做了异步化入场时车牌识别和开闸是低延迟需求但识别回调结果并不需要实时写库可以用MQ或线程池异步更新进场记录接口立刻返回响应。最后再分享一个项目后期的扩展思路这个系统核心表和状态机设计已经稳定后续如果要做“共享车位”的C2C模式只需要增加space_owner表、分润计算模块和车主端的发布流程核心的车位状态机、订单支付体系都能直接复用。如果要做多停车场集团化运营只需要在parking_lot表上增加集团ID字段再对管理端做数据权限隔离即可。从我实际开发的经验来看这个项目最大的价值不在于某个技术点有多新而在于它把“租赁业务”这种包含时间、状态、并发、金额的复杂场景用一套相对简单且可维护的方式落地了。系统上线后停车场月度租赁收入提升了一倍多运营人员不再手工对账用户也不再为找不到固定车位发愁。如果你正在规划类似系统建议先把订单状态机和车位状态机的边界想清楚然后动手写代码这套方案可以大幅降低你后期改需求的成本。