ThinkPHP+Vue智能停车场管理系统：从车位分配到计费闭环

1. 项目概述与需求拆解

1.1 这个系统到底要做什么

停车场管理这个事儿，看起来简单，真做起来涉及的细节其实不少。很多小型停车场还在用最原始的方式：门口保安拿个本子登记车牌，车主离场时翻本子算时间、算费用。这种方式在车辆少的时候勉强能撑，一旦车流量上来，出入口就开始排队，晚上对账更是容易出错。

我做的这个“thinkphp+vue智能停车场车辆停车车位系统”，核心目标就是把车辆进场、车位分配、费用计算、订单管理这一整条链路搬到线上，用前后端分离的架构实现一套可复用的停车场管理方案。后端用ThinkPHP提供API接口，前端用Vue构建管理页面和用户端页面，数据统一存储在MySQL里。

这个系统的使用角色分两类：一类是停车场管理员，负责管理车位资源、查看停车记录、处理异常订单；另一类是车主用户，可以查看车位余量、查询自己的停车记录、完成线上缴费。整个流程可以概括为：车辆进场时记录入场信息并分配车位，停车过程中实时维护车位状态，车辆离场时根据停车时长自动计算费用，车主完成支付后订单闭环。

1.2 从需求分析到模块划分

在动手写代码之前，我先把需求拆成了几个明确的模块。这个步骤很关键，如果不提前想清楚边界，后面开发过程中很容易出现功能互相纠缠的情况。

首先是车位管理模块。一个停车场有地面车位、地下车位，可能还有不同区域，每个车位都有自己的编号和状态。状态我设计了三种：空闲、占用、预留。空闲就是没车停，占用就是有车正在停，预留是给月租车主或者特殊车辆保留的。

其次是车辆管理模块，记录每一辆车的车牌号、车辆类型、车主信息。这里要注意一个细节：临时车和月租车的处理逻辑完全不同。临时车进场需要分配一个空闲车位，离场时按小时计费；月租车进场只需要核验月租是否在有效期内，不涉及临时计费。

然后是停车记录模块。每一次进场、每一次离场都要生成一条完整的记录，包括车牌号、进场时间、离场时间、停放车位、应缴费用、实缴费用、支付状态这些字段。这个模块是后面统计报表的数据基础。

最后是订单与计费模块。计费规则是停车场运营方的核心诉求，不同停车场收费标准差异很大，有的是按小时计费，有的是首小时多少钱、后续每半小时多少钱，还有封顶价格。设计时我把计费规则做成可配置的，而不是写死在代码里。

1.3 技术栈选型背后的思考

为什么选ThinkPHP而不是别的后端框架？原因有三个：第一，ThinkPHP在国内的使用基数大，遇到问题网上能搜到的案例多，团队维护成本低；第二，ThinkPHP 8的架构对前后端分离模式支持得比较成熟，写API接口的体验很顺畅；第三，这个项目对性能的极致要求不高，ThinkPHP的生态完全够用，不必为了追求高并发引入更重的框架。

前端选Vue，同样考虑了团队熟悉度和生态。Vue 3的组合式API写业务代码很舒服，配合Element Plus做管理后台界面，组件齐全，开发效率很高。移动端的用户页面我用的是Vue生态下的移动端组件库，这样一套技术栈可以覆盖PC管理和移动端展示两个场景。

数据库选MySQL，没什么好纠结的，关系型数据用MySQL最合适，停车记录、订单这类数据有很强的事务性要求。服务器环境是常规的Linux + Nginx + PHP，生产环境部署没什么特殊门槛。

2. 数据库设计与核心表结构

2.1 用户与车辆信息的表设计

数据库设计是这类系统的地基，地基没打好，后面业务逻辑写起来处处别扭。我主要设计了六张核心表，先说用户和车辆这两张。

用户表我命名为user，主要字段有：

这里要提醒一下，数据库里的时间字段我统一用int类型存时间戳，而不是用datetime。原因很简单：后端做时间计算和格式化的时候，时间戳可以直接运算，不用反复做字符串转换，而且跨时区问题也不容易出现。很多初学者喜欢用datetime，一开始觉得直观，后面做计费时长计算的时候就会难受。

车辆表car的核心字段是car_number（车牌号）、car_type（车辆类型）、user_id（所属用户ID）。车牌号要加唯一索引，因为同一辆车不应该重复建档。车辆类型我分了小型车、大型车、新能源车三种，之所以区分新能源车，是因为不少停车场对新能源车有充电车位或者收费优惠。

这里涉及到一个关联查询的细节：一次停车记录要查车牌号、查车主信息、查车位编号，如果全部用ORM层层关联，效率不高。我在实际开发中习惯在查询条件里直接指定字段，只查出需要的列，避免select *带来的无效数据传输。

2.2 车位资源管理表

车位表parking_space的设计核心在于状态字段和绑定关系。表结构大概是：

这里有个容易忽视的点：car_id字段设计的时候是可空的。车位空闲时这个字段是NULL，车辆进场时写入对应的车辆ID。很多新手会把车位和车辆做成强绑定，进场就把车辆写死，离场再解除，这样如果中途出现异常流程，数据的完整性很难维护。

status和car_id这两个字段是存在联动关系的，但我在设计时没有用外键约束，而是在业务代码层保证一致性。项目规模不大，外键约束带来的额外维护成本不划算，容易出现死锁和性能损耗。这个选择在单机部署、并发量不高的场景下是合理的。

另外，车位表还要预留一个扩展字段，比如是否支持预约、预约时间窗口等。这类灵活字段我建议用单独的配置表或者JSON字段存储，不要每加一个功能就改一次表结构。

2.3 停车记录与订单计费表

停车记录表parking_record是这个系统的业务核心，字段设计如下：

这张表里exit_time为NULL时表示车辆还在场内，离场时更新这个字段并写入duration和amount。金额字段用decimal类型，精确到小数点后两位，绝对不要用float，否则金额计算会出现精度丢失。

订单表parking_order主要记录支付相关的信息，包括订单号、支付方式（微信/支付宝）、支付金额、支付状态。订单号的生成规则我用的是日期时间加随机数，比如20250601123045678901，这个格式在财务对账时比较友好，一眼能看出是哪天的订单。

关于status字段的流转，我在代码里用常量类来管理，STATUS_PARKING = 0、STATUS_WAIT_PAY = 1、STATUS_PAID = 2，这样可以避免魔法数字散落在代码各处。将来如果加一个“申诉中”状态，只需要在这个常量类里增加一个常量，涉及状态判断的地方都用常量比对，不会漏改。

3. 后端API设计与业务逻辑实现

3.1 进场流程：从请求到车位分配

进场接口是车辆进入停车场时的核心入口，我用POST /api/vehicle/entry接收前端传来的车牌号和车辆类型。业务处理流程是这样的：

先根据车牌号查询车辆档案，如果查不到，就自动创建一条临时车辆记录。这样设计是为了兼容那些没有注册会员的临时车辆——保安只需要输入一个车牌号，系统自动把后续流程走完。

接着查空闲车位。查询条件包含两个：status = 0（空闲）和type = 车辆类型对应车位类型。如果找不到空闲车位，接口直接返回“车位已满”，同时提示最近有哪个区域的车位即将释放，这需要关联查询在停车辆的预计离场时间。

分配车位时的并发问题，我在后面会专门讲，这里先说一下基本逻辑：查询到空闲车位后，启动事务，把车位状态改为占用、写入车辆ID，同时插入一条停车记录。整个过程必须在事务里执行，防止多辆车同时抢到同一个车位。

这里还有一个容易踩坑的细节：车位分配成功之后，前端要能明确知道车辆停在了哪个区域、哪个编号。所以接口返回的数据除了成功标识，还要带上area和space_no字段。很多系统在这个环节只返回一个成功状态，车主进场后转了半天不知道停哪儿，那是交互设计上的失败。

3.2 出场结算：时长计算和计费规则

出场接口POST /api/vehicle/exit接收车牌号，后端根据车牌号查询当前在停的未离场记录。计算停车时长的逻辑很简单：当前时间戳 - 进场时间戳，得到秒数，再除以60得到分钟数。

这里有个取舍：首页停车不足一小时按一小时收费，还是按实际分钟计费？我在项目里做成了可配置项。配置化计费是通过一张计费规则表charging_rule来实现的，里面定义了规则名称、免费时长、首小时费用、续小时费用、单日封顶金额等字段。系统启动时读取配置加载到缓存，计算费用的时候直接调用规则引擎，不需要写死。

计费计算的代码逻辑大概是：

// 伪代码，体现核心逻辑 public function calcAmount($durationMinutes, $rule) { $freeMinutes = $rule['free_minutes']; // 免费时长 if ($durationMinutes <= $freeMinutes) { return 0; } $billableMinutes = $durationMinutes - $freeMinutes; $hours = ceil($billableMinutes / 60); // 向上取整 $amount = $rule['first_hour_fee'] + max(0, $hours - 1) * $rule['additional_hour_fee']; // 封顶判断 if ($rule['daily_cap'] > 0 && $amount > $rule['daily_cap']) { return $rule['daily_cap']; } return $amount; }

用ceil向上取整是模拟停车场“不足一小时按一小时算”的常见规则。如果停车场按每半小时计费，只需要把这里的除数改成30即可。这个函数写得尽量通用，方便不同项目复用。

离场操作同时要把车位状态改回空闲，解除车辆与车位的绑定关系，并把停车记录的状态更新为待支付。这三个动作同样在一个事务内完成。

3.3 状态流转的约束条件

停车记录的状态流转在业务上有严格的时序要求：停车中只能变为待支付，待支付只能变为已支付或者发起申诉。我在代码里加了一个状态变更的校验方法，每次更新状态前先判断当前状态是否允许执行这个操作。

// 状态流转校验 private function canChangeStatus($currentStatus, $targetStatus) { $allowedTransitions = [ self::STATUS_PARKING => [self::STATUS_WAIT_PAY], self::STATUS_WAIT_PAY => [self::STATUS_PAID, self::STATUS_APPEAL], self::STATUS_PAID => [], self::STATUS_APPEAL => [self::STATUS_PAID, self::STATUS_WAIT_PAY], ]; return in_array($targetStatus, $allowedTransitions[$currentStatus] ?? []); }

这样做的好处是，就算前端误操作或者有人直接调API接口，也不会把一条停车记录的状态改到乱七八糟。类似的约束逻辑同样应用于车位状态：只有空闲的车位才能被占用，只有被占用的车位才能被释放。

3.4 API接口设计规范

接口设计上，统一返回格式很重要。我的项目里所有接口都遵循{code: 200, message: 'success', data: {...}}的格式。前端的请求封装会统一拦截code字段，如果不是200，就弹出对应的message提示。

对于列表接口，统一用GET请求加分页参数；对于创建、更新操作，用POST请求。本项目没有引入复杂的前后端契约工具，直接用接口文档来约定字段，文档是开发过程中最重要的沟通依据。

登录鉴权用的是JWT方案。用户登录成功后，后端签发一个有效期两小时的token，前端存在本地存储中，每次请求在请求头带上Authorization: Bearer token。后端在中间件里统一解析token并校验有效期，解析失败时返回401，前端检测到401就跳转到登录页。

4. 前端Vue页面设计与交互实现

4.1 页面架构与路由设计

前端项目基于Vue 3 + Vite构建，路由层面划分为两个大的区域：管理端和用户端。

管理端路由挂在/admin路径下，包含数据概览、车位管理、停车记录、订单管理、车辆管理等页面。用户端路由挂在/park路径下，包含车位余量展示、停车记录查询、在线缴费等页面。

路由设计时用到了路由守卫。管理端页面统一加权限校验，判断当前登录用户的role字段是否为管理员，如果不是就直接跳转到用户页面。这个守卫是在前端做的，后端接口同样做了权限校验，双保险。

页面布局用了侧边栏加顶部的经典结构。侧边栏放导航菜单，顶部放用户信息和退出按钮。这个结构看起来常规，但确实是最适合管理后台的布局方案，操作路径短、目标明确。

4.2 关键交互：剩余车位实时展示

用户端最核心的页面是车位余量展示页。页面顶部展示停车场总车位数、当前剩余车位数、充电车位数三个核心数字。这个页面我用了轮询的方式更新数据：组件挂载后，每隔10秒调用一次车位统计接口，拿到最新的数据刷新页面。

为什么不接入WebSocket？我之前在另一个项目里用过WebSocket做实时推送，架构上确实更“先进”，但部署运维成本明显增加。停车场场景下，10秒刷新一次已经足够实时，而且轮询逻辑极其简单，稳定性更高。这也是一个典型的“用合适的技术而不是最酷的技术”的案例。

车位的可视化展示用了一个简单的网格布局，每个格子是一个车位，颜色区分状态：绿色代表空闲，红色代表占用，灰色代表预留。这个界面实际交付后被客户重点表扬过，说比原来纯文字列表直观多了。

4.3 管理端核心页面实现

管理端的数据概览页面，展示了今日进场车次、今日离场车次、今日营收、当前在场车辆数四个统计卡。这些数据通过一个聚合接口返回。实际上，这个聚合接口的压力在于SQL性能，我用了两次分组查询和一次金额汇总，避免了多条SQL轮询数据库。

车位管理页面就是一个表格，支持按区域筛选、按状态筛选。状态变更操作放在每行后面，空闲的可以“手动占用”，占用的可以“强制释放”。“强制释放”这个功能是运营方特别要求的，有时候车辆出场时设备没扫到车牌，需要管理员手动干预。

车位的增删改页面用了一个Dialog弹窗，表单里包含车位编号、区域、类型三个字段。新增车位时后端会做重复校验，车位编号不能重复。

4.4 缴费流程与支付对接

在线缴费的流程是这样的：用户查询自己的停车记录，看到待支付订单，点击支付按钮，后端生成一个支付链接跳转到支付平台收银台。支付完成后平台异步回调通知后端，后端更新订单状态为已支付。

支付回调这里有一个很重要的细节：回调接口不做任何业务判断，只做状态更新，而且更新操作是幂等的。什么叫幂等？就是同一个支付成功的回调通知，哪怕收到两次三次，执行的结果都应该是相同的。实现方式是在更新之前先查询当前订单状态，只有待支付状态下才执行更新，如果已经是已支付就直接返回成功。

这个项目里支付部分我封装了一个支付服务类，把支付平台的请求和回调处理逻辑单独隔离出来。这样将来如果换一个支付渠道，只需要重写这个服务类的内部实现，业务代码完全不用动。

5. 后端接口的并发处理与数据一致性

5.1 车位超卖问题的根源

车位“超卖”是这类系统里最典型也最致命的Bug。场景是这样的：两辆车同时进场，查询空闲车位时都看到车位A是空闲的，然后同时执行占用操作，结果两辆车都停到了同一个车位上。

出现这个问题的根本原因是“先查询再更新”的时序漏洞。我在项目初期也踩过这个坑，第一次联调测试时就复现了，当时就下定决心必须解决。

5.2 悲观锁与唯一索引的双重防护

我采用的方案有两层。第一层是数据库层面的唯一约束：车位占用时在停车记录表里写入当前车位ID，并保证“车位状态为占用”的车位ID在停车记录表中没有未离场的重复记录。这个约束用数据库的联合唯一索引来实现，例如在parking_record表加一个uk_space_status的唯一索引，覆盖space_id和status字段的部分索引（MySQL不支持部分索引，实际方案是在代码层处理）。

实际落地时，我用了更直接的方式：在查询空闲车位时加上FOR UPDATE悲观锁。

SELECT * FROM parking_space WHERE status = 0 AND type = '小型车' LIMIT 1 FOR UPDATE

这个操作会在事务内锁定这一行车位记录，其他事务必须等待当前事务提交或回滚后才能继续操作这个车位。配合外层的事务控制，可以做到：抢到锁的请求完成车位状态更新并提交，其他请求在锁释放后重新执行查询时，这个车位已经是占用状态，自然不会再次分配。

这种方案在低并发场景下完全够用。如果将来车辆高峰期并发量上来了，可以把分配逻辑改造成队列化处理，或者引入Redis分布式锁来做更细粒度的控制。

5.3 事务边界的合理划分

我在写事务代码时，特别强调“事务要尽量短”。一个事务里只包含“查询车位 – 占用车位 – 写入停车记录”这三个操作，至于车牌号查询、车辆创建这些前置逻辑，都放在事务之外。

这样做是因为事务持有的是数据库连接资源，如果事务时间过长，连接池会被耗尽，整个系统的吞吐量就下来了。有很多人把事务当成万能药，把无关操作全都塞进去，最后性能出问题还不知道怎么回事。

同样的原理也用在离场结算上：查询停车记录和计算费用不需要事务，只有“更新车位状态、更新记录状态”这两个写操作需要放在事务里。计算费用这种CPU操作，完全可以在事务外完成。

6. 前端与后端的联调细节

6.1 跨域问题的处理

前后端分离项目必然要处理跨域。开发环境下，前端跑在5173端口，后端跑在8000端口，浏览器默认会拦截跨域请求。我的处理方式是在后端统一添加跨域中间件，允许指定来源访问。

// 跨域中间件关键代码 public function handle($request, \Closure $next) { $response = $next($request); $response->header('Access-Control-Allow-Origin', '*'); $response->header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS'); $response->header('Access-Control-Allow-Headers', 'Authorization, Content-Type'); return $response; }

生产环境部署时，我把前端构建后的静态文件放在Nginx里，通过反向代理把/api路径转发到PHP服务，由Nginx统一处理静态资源和API转发，这样跨域问题在服务器层面就解决了，不需要在代码里放开限制。

这里想多说一句：Access-Control-Allow-Origin设置成*在开发环境无所谓，生产环境建议还是改成具体域名，安全等级完全不同。

6.2 接口调试的实用经验

调试接口我用的是Postman，但团队协作时会导入一份公开的接口文档。每个接口的请求参数、返回示例、异常码都会提前约定清楚。描述返回数据时，我习惯提供两个示例：一个成功返回，一个失败返回。

前端拿到接口文档后，会先根据返回的数据结构定义出对应的JavaScript模型类或者TypeScript接口类型。这样在写页面的时候，数据结构是明确的、类型是安全的，不会出现一个字段名两边拼写不一致，页面报错却找不到原因的尴尬情况。

6.3 前端请求封装和错误拦截

前端请求封装是我比较重视的一部分。我在utils/request.js里统一配置了axios实例，包括基础URL、请求头、超时时间。响应拦截器里做的事情有两件：正常数据直接返回response.data.data，方便页面代码拿到业务数据直接使用；异常状态码统一跳转或者弹提示。

特殊情况要特殊处理：当后端返回401时，说明token失效了，这个时候应该清除本地登录状态并跳转到登录页。这个逻辑放在拦截器里，所有接口自动生效，不需要每个接口单独处理。

7. 常见问题与排查技巧

7.1 车辆离场后车位状态没恢复

这个问题的表现是：车辆已经离场了，但车位上显示的还是红色占用状态。排查步骤我一般按下面这个顺序来：

第一步，看停车记录表的离场接口有没有正常返回。如果返回了成功，但车位状态没变，多半是事务里的更新语句没执行到。第二步，检查后端日志，看更新车位状态时有没有抛出异常。第三步，检查代码里更新车位状态时使用的条件是space_id，如果一个车位的space_id在记录中为空，就会出现更新不到任何记录的情况。

这种问题我在开发中遇到过好几次，后来学到的教训是：离场业务的代码必须写好日志，每一关键步骤都打一条日志。这样出了问题，看日志能直接定位到哪一步断了，不用靠猜。

7.2 token过期和前端页面失效

前后端分离模式下，token有效期的设置要平衡安全性和用户体验。太短用户经常要重新登录，太长又不安全。我建议管理端token有效期两小时，用户端可以放宽到一天。

当用户页面操作时突然跳回登录页，排查第一件事是看浏览器本地存储里还有没有token。如果token还在，就需要看后端解析token时有没有报过期异常。如果本地存储是空的，说明可能是前端在某个时刻执行了清理操作，这个要检查响应拦截器是否有误杀。

7.3 计费金额异常

计费异常属于最容易被投诉的bug，处理优先级最高。我遇到过的典型案例是：跨天停车没有按单日封顶计算，结果车主停了两天，显示的费用是一天费用的四倍。

问题出在封顶规则只判断了总时长对应的金额是否超过封顶，但没有把跨天场景拆分处理。正确的逻辑应该是：超过当天封顶后，第二天的费用重新从首小时费用开始计算。这块逻辑看起来简单，实际推到边界情况时会发现很多细节，我把计费规则引擎抽出来，用单元测试覆盖了各种边界场景，比如：免费时长内的订单、超过封顶的订单、跨天的订单。

7.4 排查问题时的数据库面板

排查效率的提升，很大程度上依赖数据库查询效率。我开发时习惯开一个数据库查询面板，随时查看记录的最新状态：

SELECT * FROM parking_record WHERE car_number = '测试车牌' ORDER BY id DESC LIMIT 10; SELECT * FROM parking_space WHERE space_no = 'A-001';

这两条SQL基本能覆盖大部分问题场景的定位。先看停车记录有没有正常生成、状态对不对，再看车位状态和记录是否匹配。这两个表的信息一对上，问题往往就浮出水面了。

8. 部署上线与后续扩展思路

8.1 部署流程的简化方案

项目开发完成后，部署是我花了一整天来优化的环节。最终的生产环境配置方案是这样的：

服务器装好Nginx和PHP环境，PHP版本要求8.0以上。后端代码上传到服务器后，配置伪静态规则，/api路径下的请求统一转发到ThinkPHP的入口文件。前端代码在本地构建生成dist目录，上传到Nginx的静态站点目录。

构建命令很简单：

npm run build

构建完成后，dist目录下的文件就是纯静态资源，Nginx直接托管。这里有个小坑需要提醒：前端路由如果用history模式，Nginx需要配置try_files，否则直接访问某个子路由时，Nginx会返回404，只有从首页进入前端的应用才能正常访问内部路由。最初项目刚部署时我就踩了这个坑，后来在配置里补上了。

8.2 缓存与性能提升

性能优化的第一步是给接口加缓存。车位统计接口的响应时间被优化到了毫秒级。

这里说一下我的冗余设计思路：在车位表里冗余了“当前车辆ID”，在停车记录表里冗余了“当前车位ID”，这两个冗余字段的更新代价很低，但查询效率提升非常明显。比如统计今日营收，只需要扫订单表里的pay_time字段，并做一次SUM聚合，不需要关联车辆表、车位表，数据量在万级时响应时间完全可接受。

接口缓存用的是ThinkPHP自带的缓存机制，底层驱动是Redis。数据变更操作（车辆进出场、车位状态更新）会同时清除对应的列表缓存，保证用户看到的不是太旧的数据。

8.3 业务的扩展方向

这套系统的基础架构和业务模块，稍微扩展就可以接入更多场景。比如车牌识别摄像头，进场时摄像头自动识别车牌号并调用进场接口，出场时同样自动识别并推送离场请求，实现无人值守。这个改造只需要在硬件设备调用接口方面对接，核心业务代码不需要调整。

再比如预约车位功能，用户在手机端提前预约某个时段的车位，系统给这个车位打上“预留”状态，并在预约时段内不允许其他车辆占用。这个功能要新增一张预约表，业务逻辑上对车位分配模块做一些增补。

月租车管理也可以深化，按月租车辆的到期时间做自动提醒，到期前三天发送消息给车主。运维方可以在管理系统里配置不同车辆类型的月租价格。

就我个人的经验而言，这类业务系统能不能真正用起来，关键不在于技术栈多先进、架构多复杂，而在于核心业务流程是否闭环、异常情况是否兜得住、操作成本是否足够低。把基础功能做扎实，一个标题从代码变成可用的系统，后续扩展自然水到渠成。