简介基于微信小程序与Java后端构建的智能停车场管理系统是一套可用于毕业设计、课程设计与项目实战的完整资料包。系统前台围绕小程序端实现首页、地图、个人中心与车位预定等操作后台则支持管理员对用户、车位信息和预定记录进行管理技术栈覆盖微信开发者工具、Java结合SSM框架及MySQL数据库适合需要掌握前后端联动开发的在校学生。压缩包共1182个文件整体约10.99MB内容包含Java后端源码、Vue/JS前端脚本、wxml/wxss小程序页面、png/svg界面素材、数据库SQL与说明文档同时附有安装、运行、构建等批处理脚本便于本地快速部署。已有226人学习该资源。借助包内源码、数据库脚本和详细说明读者可清晰梳理项目结构、业务表设计及前后端接口交互方式较快理解车位预定、用户管理等功能实现思路为完成毕业设计或扩展智能停车类应用提供扎实基础。1. 智能停车场毕业设计都卡在哪从选题到验收的完整闭环一套以微信小程序 Java 后端为主线的智能停车场管理系统毕业设计听起来就是把“用户端小程序 管理后台 一张数据库表结构”凑在一起交差但真正动手时会发现小程序端要处理微信登录、蓝牙或模拟支付后端要扛住车位并发更新和订单计费数据库要是表设计没做对后面每一个功能的查询都变成一场灾难。这篇笔记想解决的就是把这些点全部串起来。适合谁看已经拿到类似源码包但跑不起来的人、正在选毕业设计题目想评估“这个题到底值不值得做”的人、以及想从零把前后端联调走通并顺利通过答辩的在校生。2. 先想清楚再写代码停车场的业务切分与小程序的边界2.1 再小的系统也要先画好四个数据边界很多毕业设计一上来就写CREATE TABLE写到一半发现车位、订单、用户、余额之间的关系理不清于是开始堆字段、加外键最后整个库变成一张大宽表。我一般会先画数据边界用户、车辆、车位、订单这四类东西谁是主体、谁依赖谁、谁变化最频繁画完再落表结构。用户是主体车辆挂在用户下一个用户可有多辆车。车位是资源状态分空闲、占用、锁定状态变化由进出场动作触发。订单是流水记录一次停车行为从入场到出场的完整过程。支付和优惠属于订单的附加信息不要拆成独立大表否则查询时要 join 三次以上。边界画清楚接口的粒度也就跟着出来。小程序端只需要“查车位、预约/占位、查我的订单、支付、登录”而后端多出的“车辆管理、费率设置、统计报表”归管理端。很多源码包把管理端和小程序端混在同一个工程里为了省事我习惯在同一个 Spring Boot 工程下按/api/user/**和/api/admin/**做分组这样既省掉一个独立管理端项目又能通过拦截器区分权限。2.2 微信小程序端只做三件事渲染、交互和请求小程序端不要放任何业务规则比如“月卡用户每天只能预约两次”这种逻辑放在小程序里就等于把核心规则暴露给前端换个管理后台就等于换一套业务。小程序的职责限制在三件事渲染页面、收集用户操作、把操作变成 HTTP 请求发给 Java 后端。登录是关键点。毕业设计里最常见的登录方式是wx.login()换取code再把code传给后端后端用jscode2session接口换取openid通过openid找到本地用户找不到就自动注册。注意不要在小程序端直接拿手机号当用户标识手机号只是注册时的绑定信息真正的主键是openid。还有一类很容易忽略的问题微信开发者工具里默认不校验合法域名所以本地开发可以用http://localhost:8080但真机预览时必须配置合法域名且必须是 HTTPS。这也是后面联调最容易“明明代码没问题却请求失败”的根源。2.3 Java 后端的三个关键选型理由毕业设计选 Java 后端除了课程要求更实际的理由有三个一是 Spring Boot 的生态最成熟网上能查到的停车场管理系统开源项目、博客案例最多遇到报错搜关键词基本都有解二是 MyBatis-Plus 这类 ORM 能把重复的 CRUD 代码省掉一大半对于时间紧张的毕业设计是实打实的“后悔药”后期改字段不用重写一堆 XML三是 Java 的线程模型和大并发下的表现足够撑起毕业设计演示时的“模拟百人同时扫码入场”这种并发场景比脚本语言后端更有说服力。框架选型上我建议 Spring Boot 2.x MyBatis-Plus MySQL 8认证用 JWT不要上 Spring Security 全家桶——毕业设计不需要那么重的权限框架自己写一个拦截器校验 JWT 反而更容易讲清楚。如果源码包里带的是 SSMSpring MVC Spring MyBatis老结构也不必推倒重来把分页、事务、拦截器这三个机制确认好老结构也可以完成整套小程序对接。3. 数据库设计是这套系统的地基表结构、字段与 SQL3.1 六张核心表及字段设计数据库设计是整套系统里“翻车率”最高的部分。很多拿到源码包的同学第一件事是启动后端结果报Table xxx doesnt exist原因多半是数据库脚本没导入或者导入的脚本和实体类字段对不上。为避免这个问题我在建表时把每张表的字段、类型、注释写在同一份 SQL 里并同步维护一份字段说明清单表结构长这样表名核心字段说明userid、openid、nickname、phone、balance、create_time小程序用户openid唯一索引carid、user_id、plate_number、car_type车辆信息支持一个用户多辆车parking_spaceid、space_no、area、status、lock_version车位状态0 空闲1 占用2 锁定parking_orderid、order_no、user_id、car_id、space_id、start_time、end_time、amount、status停车订单status区分进行中、已完成、已取消payment_recordid、order_id、pay_type、pay_status、amount、pay_time支付流水一个订单对应一到多条fee_ruleid、rule_name、unit_price、free_minutes、daily_cap计费规则支持按时、按次、封顶价写字段时注意三个习惯主键一律用bigint自增或雪花 ID不要用varchar存订单号当主键金额一律用decimal(10,2)禁止用float否则计费会出现 0.01 元的误差所有表都带create_time和update_timeMyBatis-Plus 可以自动填充答辩时这也是一个可以主动讲的亮点。3.2 车位状态并发更新与费率计算车位状态是最容易出并发问题的地方。设想一个场景用户 A 在小程序上看到 05 号车位空闲点击“占位”提交订单用户 B 同时提交同一个车位两个请求都通过了“状态为 0”的查询条件于是同一车位被开成两笔订单。常见做法有两种一是在parking_space表上先执行UPDATE parking_space SET status 1 WHERE id ? AND status 0通过受影响行数判断是 1 还是 0为 0 说明车位已被抢走二是用乐观锁给表加lock_version字段每次更新SET lock_version lock_version 1 WHERE lock_version ?。我更推荐第一种因为它在一条 SQL 里完成“判断 更新”不需要后端处理版本不一致的重试。费率计算的逻辑放到后端 Service 层用一个独立方法calculateFee(startTime, endTime, feeRuleId)。计算时先查fee_rule拿到免费分钟数、单价、日封顶价然后按分钟数乘单价最后和每日封顶价取小者。这些边界条件免费时段、跨天、封顶必须写在文档里答辩时老师大概率会追问“跨天停车怎么计费”。3.3 用 SQL 实现订单与流水联动订单生成和支付流水写入不能分成两条独立逻辑否则会出现“订单已支付但流水表没记录”或者反过来。我的做法是创建订单时先插parking_order状态为“进行中”用户发起支付时后端在一个事务里完成“更新订单金额和状态 插入支付流水 扣减用户余额”任一步失败则整体回滚。核心代码结构如下Transactional(rollbackFor Exception.class) public PayResult payOrder(PayRequest req) { // 1. 幂等校验同一订单不能重复支付 ParkingOrder order orderMapper.selectById(req.getOrderId()); if (order null || order.getStatus() ! ORDER_STATUS_PENDING) { throw new BizException(订单不存在或已支付); } // 2. 查余额并做版本事务更新 User user userMapper.selectById(order.getUserId()); int rows userMapper.deductBalance(user.getId(), order.getAmount()); if (rows 0) { throw new BizException(余额不足); } // 3. 更新订单状态 插入支付流水 orderMapper.updateStatus(order.getId(), ORDER_STATUS_PAID); PaymentRecord record new PaymentRecord(); record.setOrderId(order.getId()); record.setAmount(order.getAmount()); record.setPayStatus(PAY_SUCCESS); paymentRecordMapper.insert(record); return PayResult.success(order.getAmount()); }这段代码的逻辑要点有三个Transactional保证步骤 2 和步骤 3 要么同时成功要么同时回滚deductBalance的 SQL 要写成UPDATE user SET balance balance - #{amount} WHERE id #{userId} AND balance #{amount}由数据库保证不产生负余额幂等校验放在事务开头防止前端重复点击或网络重试导致重复扣款。参数上重点是rollbackFor Exception.class很多模板默认只在RuntimeException时回滚如果你抛的是自定义业务异常还继承自Exception就会遇到“扣款了但订单没更新”的诡异问题。4. 把工程跑起来项目结构、配置文件与最小启动步骤4.1 工程拆解为什么后端按 controller、service、mapper 分层我拿到过一个源码包后端只有一个巨型ParkingApplication.java所有业务都写在 Controller 里一个接口几百行读代码时想找到底哪一段在计算费用要翻五分钟。后来我把工程按经典三层拆开Controller 只做参数接收和结果包装Service 做业务编排Mapper 只写 SQL。这样拆的好处是答辩时被问到“你的系统怎么保证可维护性”你能现场指出依赖方向是单向的不用模棱两可地说“是照着模板写的”。项目结构建议这样组织parking-backend/ src/main/java/com/example/parking/ controller/ # 小程序端接口AuthController, SpaceController, OrderController service/ # 业务逻辑OrderService, UserService, FeeService mapper/ # MyBatis-Plus 的 Mapper 接口 entity/ # 与数据库表对应的实体类 config/ # WebMvc 配置、拦截器、跨域配置 common/ # 统一返回结果、全局异常处理 src/main/resources/ application.yml mapper/ # 复杂 SQL 的 XML 文件4.2 小程序端的最小跑通路径小程序端拿到的源码一般是一个完整工程第一步先确认项目是用原生小程序写的还是用 uni-app 写的。原生小程序的目录里会有app.js、app.json、pages/和project.config.json如果是 uni-app 工程根目录会多出src/或者pages.json风格的结构并且要用 HBuilderX 导入而不是微信开发者工具直接打开。这两个方向搞混了会出现“打开一片空白”或者“找不到 app.json”。跑起来的最小路径在微信开发者工具中导入项目填入自己的小程序 AppID测试号也可以打开app.js检查globalData.baseUrl是否指向本地后端地址例如http://localhost:8080。然后在开发者工具的“详情 - 本地设置”里勾选“不校验合法域名”这是本地调试的通行证。之后切到“编译模式”如果能看到首页车位列表说明小程序的基本渲染和首页接口已经通了一半。4.3 Java 后端与小程序联调的配置文件清单后端项目里最常被忽略的文件是application.yml而 80% 的“接口连不上”都和它有关。我常用的配置结构如下其中连接数据库的地址、账号密码、JWT 密钥都要改成自己的server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/parking_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath:/mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl jwt: secret: your-secret-key-change-me expire-hours: 24这里要注意的是 URL 里的serverTimezoneAsia/Shanghai如果不加本地 MySQL 8 会报时区相关的连接错误map-underscore-to-camel-case开启后数据库的plate_number才能自动映射到实体的plateNumber少这一行你会看到一大堆字段为 null 的诡异现象。log-impl打开 SQL 日志联调阶段不要关它能帮你确认每一次请求实际执行了什么语句。4.4 联调顺序与效果确认联调不要太贪心一上来就测支付流程那样出问题时你又分不清是小程序问题、后端问题还是数据库问题。我习惯按这个顺序来第一步小程序的“登录”按钮能把code换成后端返回的token并能在控制台打印出用户信息第二步“车位列表”页面能显示数据库里的真实车位状态第三步“预约占位”后刷新列表同一车位状态从 0 变 1第四步模拟支付后订单状态变成已支付用户余额正确扣减第五步做一次“余额不足”的异常流程确认后端返回了友好的错误消息而不是一条 500 堆栈。每完成一步在后端控制台确认 SQL 日志和接口返回同时在小程序network面板看请求状态码是不是 200。联调阶段的拦路虎通常不是代码而是地址写错——小程序的baseUrl用了局域网 IP 但手机和后端不在同一网络这种问题排查起来特别像玄学但原因其实很简单。5. 典型的坑与排查路径从微信回调到数据库死锁5.1 微信小程序登录态和 openid 的坑现象本地调试时登录成功但过一会儿所有带登录态的请求都返回401或token 失效。原因微信小程序端的wx.login()生成的code是一次性的后端换取openid后如果前端在小程序启动时重复调用wx.login()会刷新 code 并让旧 code 失效更常见的是 token 过期时间设置太短比如 30 分钟用户停在页面上超过这个时间再操作就失效。解决前端把token存到wx.setStorageSync后端把token过期时间设为 24 小时并在每次请求前做一次无状态的 JWT 校验小程序端加一个“登录态失效后自动重新登录”的拦截逻辑不要只在失败时弹个框让用户手动退出。5.2 “请求被拒”的四种常见原因现象小程序端请求后端接口返回request:fail或者statusCode 404/500后端日志里却没有任何相关记录。原因第一baseUrl写错比如漏了端口号第二开发者工具勾选了校验合法域名但本地地址是http被拦下第三后端没开跨域浏览器和微信小程序的请求被同源策略拦截第四真机预览时手机访问的是localhost而localhost指向手机本身而不是电脑。解决先用电脑浏览器直接访问http://localhost:8080/api/health确认后端在线后端用拦截器对/api/**统一加Access-Control-Allow-Origin真机调试时把baseUrl改成电脑的局域网 IP并且确保手机和电脑在同一 Wi-Fi。这里有个血泪经验改完配置一定要“重新编译小程序 重启后端”微信开发者工具经常缓存旧配置改完不重启就继续报一样的错特别容易让人误判。5.3 车位状态并发更新时出现的“幽灵占用”现象两个账号同时占同一个车位两个都提示成功车位列表显示被同一个车牌占用但订单列表里却只有一条记录。原因后端代码是“先select判断状态再update改状态”两个请求同时通过select时都读到status0于是都进入update数据库没有做原子性的状态变更。解决把判断和更新合并到一条 SQLUPDATE parking_space SET status 1 WHERE id #{spaceId} AND status 0后端检查int rows spaceMapper.occupySpace(spaceId); if (rows 0) { throw new BizException(车位已被占用); }。这样无论多少请求同时进来数据库行锁保证只有一条UPDATE会影响行数其他请求拿到 0 行就会走失败分支。注意不要在事务里长时间持锁后再去查其他表否则并发高时会出现数据库锁等待超时。5.4 数据库字符集导致的“中文乱码”现象后台录入的车位区域显示为??小程序的用户昵称变成问号。原因建表时字符集用了latin1或者连接串里没有指定characterEncodingutf8。解决统一把库、表、连接串三者都改成utf8mb4。贴一段检查用的 SQLSHOW CREATE TABLE parking_space; ALTER TABLE parking_space CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;同时确保application.yml里的连接串带了useUnicodetruecharacterEncodingutf8。改成之后最好把表里的脏数据清掉重新插入因为ALTER TABLE不会自动把已经存成乱码的数据修复过来。5.5 说明文档与代码对不上的坑现象阅读源码里的说明文档发现文档里的接口路径、字段名和代码不一致按文档调用接口直接 404。原因毕业设计源码包里的文档常常是从旧版系统复制过来的代码改了一版文档没跟上或者文档只写了核心流程没有覆盖异常分支。解决拿到源码先以代码为准不要以文档为准。先启动后端把带RequestMapping的接口路径全部列出来然后用 Postman 或 curl 逐个问一遍把文档和实际返回有差异的地方用批注标出来。答辩时主动说“我核对过文档与代码并修正了哪些差异”这是一个非常加分的细节。6. 验证系统能不能交三类测试与压测入门毕业设计不是“能跑就行”验收时老师会现场点几个功能甚至模拟并发操作所以最后的验证要覆盖接口层、小程序端和并发场景三层。接口层用 curl 做冒烟测试最直接。以下三个命令分别验证登录、查车位、创建订单这三个最核心链路# 获取 token假设登录接口需要 code这里用固定值模拟 curl -X POST http://localhost:8080/api/user/login \ -H Content-Type: application/json \ -d {code:test_code_001} # 带 token 查询车位列表 curl http://localhost:8080/api/space/list \ -H Authorization: Bearer token # 提交占位订单 curl -X POST http://localhost:8080/api/order/create \ -H Authorization: Bearer token \ -H Content-Type: application/json \ -d {spaceId:1,carId:1}这三个命令能通过的接口层的主链路就没有大问题。如果某个命令返回了 500直接用返回里的异常信息定位不要拿页面反复点。小程序端手测要按“里程碑”来登录、选车位、提交订单、查看订单详情、支付、余额扣减、余额不足提示、车牌绑定、车位状态刷新。每一步不仅仅是“看起来正常”还要在开发者工具的 Network 面板里核对请求参数和后端返回。我见过最典型的手测错误是界面显示“预约成功”但后端 MySQL 里根本没有新订单原因是前端只调了模拟接口没有调真实接口这种问题验收时一查数据库立刻穿帮。并发验证用 JMeter。创建一个线程组设置 100 个线程同时请求“占位接口”观察返回里有多少成功、多少失败“车位已被占用”的数量加起来应当和车位总数一致且订单表和车位状态保持匹配。这个测试同时还能检验数据库连接池配置是否够用如果 100 个请求里有大量超时优先检查spring.datasource的连接池上限和max-wait参数。验证之外再分享一个省钱技巧这类“用户端小程序 管理端看板”的结构不止能用于停车场稍作改动能复用在球鞋寄存、会议室预约、实验室机位管理这些预约类场景。如果你想基于这套方案做二次开发不要动核心的订单和资源状态表只换掉页面文案和计费规则即可。我自己就是这么做的把一次停车场的毕业设计改造成内部会议室预约工具只花了三天核心的占位、取消、超时释放逻辑一行没改。这是这套编程模型最值得投入的地方——它不是一次性的作业而是一套可以反复套用的预约业务骨架。希望这个方向的分析能帮到你。如果你正在调联调或者改表结构先按第 4 章的最小路径跑通再碰并发和支付那些“玄学报错”八成是域名、地址、缓存三件事没理清。本文还有配套的精品资源点击获取 智能停车场微信小程序毕业设计：从数据库设计到前后端联调
简介基于微信小程序与Java后端构建的智能停车场管理系统是一套可用于毕业设计、课程设计与项目实战的完整资料包。系统前台围绕小程序端实现首页、地图、个人中心与车位预定等操作后台则支持管理员对用户、车位信息和预定记录进行管理技术栈覆盖微信开发者工具、Java结合SSM框架及MySQL数据库适合需要掌握前后端联动开发的在校学生。压缩包共1182个文件整体约10.99MB内容包含Java后端源码、Vue/JS前端脚本、wxml/wxss小程序页面、png/svg界面素材、数据库SQL与说明文档同时附有安装、运行、构建等批处理脚本便于本地快速部署。已有226人学习该资源。借助包内源码、数据库脚本和详细说明读者可清晰梳理项目结构、业务表设计及前后端接口交互方式较快理解车位预定、用户管理等功能实现思路为完成毕业设计或扩展智能停车类应用提供扎实基础。1. 智能停车场毕业设计都卡在哪从选题到验收的完整闭环一套以微信小程序 Java 后端为主线的智能停车场管理系统毕业设计听起来就是把“用户端小程序 管理后台 一张数据库表结构”凑在一起交差但真正动手时会发现小程序端要处理微信登录、蓝牙或模拟支付后端要扛住车位并发更新和订单计费数据库要是表设计没做对后面每一个功能的查询都变成一场灾难。这篇笔记想解决的就是把这些点全部串起来。适合谁看已经拿到类似源码包但跑不起来的人、正在选毕业设计题目想评估“这个题到底值不值得做”的人、以及想从零把前后端联调走通并顺利通过答辩的在校生。2. 先想清楚再写代码停车场的业务切分与小程序的边界2.1 再小的系统也要先画好四个数据边界很多毕业设计一上来就写CREATE TABLE写到一半发现车位、订单、用户、余额之间的关系理不清于是开始堆字段、加外键最后整个库变成一张大宽表。我一般会先画数据边界用户、车辆、车位、订单这四类东西谁是主体、谁依赖谁、谁变化最频繁画完再落表结构。用户是主体车辆挂在用户下一个用户可有多辆车。车位是资源状态分空闲、占用、锁定状态变化由进出场动作触发。订单是流水记录一次停车行为从入场到出场的完整过程。支付和优惠属于订单的附加信息不要拆成独立大表否则查询时要 join 三次以上。边界画清楚接口的粒度也就跟着出来。小程序端只需要“查车位、预约/占位、查我的订单、支付、登录”而后端多出的“车辆管理、费率设置、统计报表”归管理端。很多源码包把管理端和小程序端混在同一个工程里为了省事我习惯在同一个 Spring Boot 工程下按/api/user/**和/api/admin/**做分组这样既省掉一个独立管理端项目又能通过拦截器区分权限。2.2 微信小程序端只做三件事渲染、交互和请求小程序端不要放任何业务规则比如“月卡用户每天只能预约两次”这种逻辑放在小程序里就等于把核心规则暴露给前端换个管理后台就等于换一套业务。小程序的职责限制在三件事渲染页面、收集用户操作、把操作变成 HTTP 请求发给 Java 后端。登录是关键点。毕业设计里最常见的登录方式是wx.login()换取code再把code传给后端后端用jscode2session接口换取openid通过openid找到本地用户找不到就自动注册。注意不要在小程序端直接拿手机号当用户标识手机号只是注册时的绑定信息真正的主键是openid。还有一类很容易忽略的问题微信开发者工具里默认不校验合法域名所以本地开发可以用http://localhost:8080但真机预览时必须配置合法域名且必须是 HTTPS。这也是后面联调最容易“明明代码没问题却请求失败”的根源。2.3 Java 后端的三个关键选型理由毕业设计选 Java 后端除了课程要求更实际的理由有三个一是 Spring Boot 的生态最成熟网上能查到的停车场管理系统开源项目、博客案例最多遇到报错搜关键词基本都有解二是 MyBatis-Plus 这类 ORM 能把重复的 CRUD 代码省掉一大半对于时间紧张的毕业设计是实打实的“后悔药”后期改字段不用重写一堆 XML三是 Java 的线程模型和大并发下的表现足够撑起毕业设计演示时的“模拟百人同时扫码入场”这种并发场景比脚本语言后端更有说服力。框架选型上我建议 Spring Boot 2.x MyBatis-Plus MySQL 8认证用 JWT不要上 Spring Security 全家桶——毕业设计不需要那么重的权限框架自己写一个拦截器校验 JWT 反而更容易讲清楚。如果源码包里带的是 SSMSpring MVC Spring MyBatis老结构也不必推倒重来把分页、事务、拦截器这三个机制确认好老结构也可以完成整套小程序对接。3. 数据库设计是这套系统的地基表结构、字段与 SQL3.1 六张核心表及字段设计数据库设计是整套系统里“翻车率”最高的部分。很多拿到源码包的同学第一件事是启动后端结果报Table xxx doesnt exist原因多半是数据库脚本没导入或者导入的脚本和实体类字段对不上。为避免这个问题我在建表时把每张表的字段、类型、注释写在同一份 SQL 里并同步维护一份字段说明清单表结构长这样表名核心字段说明userid、openid、nickname、phone、balance、create_time小程序用户openid唯一索引carid、user_id、plate_number、car_type车辆信息支持一个用户多辆车parking_spaceid、space_no、area、status、lock_version车位状态0 空闲1 占用2 锁定parking_orderid、order_no、user_id、car_id、space_id、start_time、end_time、amount、status停车订单status区分进行中、已完成、已取消payment_recordid、order_id、pay_type、pay_status、amount、pay_time支付流水一个订单对应一到多条fee_ruleid、rule_name、unit_price、free_minutes、daily_cap计费规则支持按时、按次、封顶价写字段时注意三个习惯主键一律用bigint自增或雪花 ID不要用varchar存订单号当主键金额一律用decimal(10,2)禁止用float否则计费会出现 0.01 元的误差所有表都带create_time和update_timeMyBatis-Plus 可以自动填充答辩时这也是一个可以主动讲的亮点。3.2 车位状态并发更新与费率计算车位状态是最容易出并发问题的地方。设想一个场景用户 A 在小程序上看到 05 号车位空闲点击“占位”提交订单用户 B 同时提交同一个车位两个请求都通过了“状态为 0”的查询条件于是同一车位被开成两笔订单。常见做法有两种一是在parking_space表上先执行UPDATE parking_space SET status 1 WHERE id ? AND status 0通过受影响行数判断是 1 还是 0为 0 说明车位已被抢走二是用乐观锁给表加lock_version字段每次更新SET lock_version lock_version 1 WHERE lock_version ?。我更推荐第一种因为它在一条 SQL 里完成“判断 更新”不需要后端处理版本不一致的重试。费率计算的逻辑放到后端 Service 层用一个独立方法calculateFee(startTime, endTime, feeRuleId)。计算时先查fee_rule拿到免费分钟数、单价、日封顶价然后按分钟数乘单价最后和每日封顶价取小者。这些边界条件免费时段、跨天、封顶必须写在文档里答辩时老师大概率会追问“跨天停车怎么计费”。3.3 用 SQL 实现订单与流水联动订单生成和支付流水写入不能分成两条独立逻辑否则会出现“订单已支付但流水表没记录”或者反过来。我的做法是创建订单时先插parking_order状态为“进行中”用户发起支付时后端在一个事务里完成“更新订单金额和状态 插入支付流水 扣减用户余额”任一步失败则整体回滚。核心代码结构如下Transactional(rollbackFor Exception.class) public PayResult payOrder(PayRequest req) { // 1. 幂等校验同一订单不能重复支付 ParkingOrder order orderMapper.selectById(req.getOrderId()); if (order null || order.getStatus() ! ORDER_STATUS_PENDING) { throw new BizException(订单不存在或已支付); } // 2. 查余额并做版本事务更新 User user userMapper.selectById(order.getUserId()); int rows userMapper.deductBalance(user.getId(), order.getAmount()); if (rows 0) { throw new BizException(余额不足); } // 3. 更新订单状态 插入支付流水 orderMapper.updateStatus(order.getId(), ORDER_STATUS_PAID); PaymentRecord record new PaymentRecord(); record.setOrderId(order.getId()); record.setAmount(order.getAmount()); record.setPayStatus(PAY_SUCCESS); paymentRecordMapper.insert(record); return PayResult.success(order.getAmount()); }这段代码的逻辑要点有三个Transactional保证步骤 2 和步骤 3 要么同时成功要么同时回滚deductBalance的 SQL 要写成UPDATE user SET balance balance - #{amount} WHERE id #{userId} AND balance #{amount}由数据库保证不产生负余额幂等校验放在事务开头防止前端重复点击或网络重试导致重复扣款。参数上重点是rollbackFor Exception.class很多模板默认只在RuntimeException时回滚如果你抛的是自定义业务异常还继承自Exception就会遇到“扣款了但订单没更新”的诡异问题。4. 把工程跑起来项目结构、配置文件与最小启动步骤4.1 工程拆解为什么后端按 controller、service、mapper 分层我拿到过一个源码包后端只有一个巨型ParkingApplication.java所有业务都写在 Controller 里一个接口几百行读代码时想找到底哪一段在计算费用要翻五分钟。后来我把工程按经典三层拆开Controller 只做参数接收和结果包装Service 做业务编排Mapper 只写 SQL。这样拆的好处是答辩时被问到“你的系统怎么保证可维护性”你能现场指出依赖方向是单向的不用模棱两可地说“是照着模板写的”。项目结构建议这样组织parking-backend/ src/main/java/com/example/parking/ controller/ # 小程序端接口AuthController, SpaceController, OrderController service/ # 业务逻辑OrderService, UserService, FeeService mapper/ # MyBatis-Plus 的 Mapper 接口 entity/ # 与数据库表对应的实体类 config/ # WebMvc 配置、拦截器、跨域配置 common/ # 统一返回结果、全局异常处理 src/main/resources/ application.yml mapper/ # 复杂 SQL 的 XML 文件4.2 小程序端的最小跑通路径小程序端拿到的源码一般是一个完整工程第一步先确认项目是用原生小程序写的还是用 uni-app 写的。原生小程序的目录里会有app.js、app.json、pages/和project.config.json如果是 uni-app 工程根目录会多出src/或者pages.json风格的结构并且要用 HBuilderX 导入而不是微信开发者工具直接打开。这两个方向搞混了会出现“打开一片空白”或者“找不到 app.json”。跑起来的最小路径在微信开发者工具中导入项目填入自己的小程序 AppID测试号也可以打开app.js检查globalData.baseUrl是否指向本地后端地址例如http://localhost:8080。然后在开发者工具的“详情 - 本地设置”里勾选“不校验合法域名”这是本地调试的通行证。之后切到“编译模式”如果能看到首页车位列表说明小程序的基本渲染和首页接口已经通了一半。4.3 Java 后端与小程序联调的配置文件清单后端项目里最常被忽略的文件是application.yml而 80% 的“接口连不上”都和它有关。我常用的配置结构如下其中连接数据库的地址、账号密码、JWT 密钥都要改成自己的server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/parking_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: mapper-locations: classpath:/mapper/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl jwt: secret: your-secret-key-change-me expire-hours: 24这里要注意的是 URL 里的serverTimezoneAsia/Shanghai如果不加本地 MySQL 8 会报时区相关的连接错误map-underscore-to-camel-case开启后数据库的plate_number才能自动映射到实体的plateNumber少这一行你会看到一大堆字段为 null 的诡异现象。log-impl打开 SQL 日志联调阶段不要关它能帮你确认每一次请求实际执行了什么语句。4.4 联调顺序与效果确认联调不要太贪心一上来就测支付流程那样出问题时你又分不清是小程序问题、后端问题还是数据库问题。我习惯按这个顺序来第一步小程序的“登录”按钮能把code换成后端返回的token并能在控制台打印出用户信息第二步“车位列表”页面能显示数据库里的真实车位状态第三步“预约占位”后刷新列表同一车位状态从 0 变 1第四步模拟支付后订单状态变成已支付用户余额正确扣减第五步做一次“余额不足”的异常流程确认后端返回了友好的错误消息而不是一条 500 堆栈。每完成一步在后端控制台确认 SQL 日志和接口返回同时在小程序network面板看请求状态码是不是 200。联调阶段的拦路虎通常不是代码而是地址写错——小程序的baseUrl用了局域网 IP 但手机和后端不在同一网络这种问题排查起来特别像玄学但原因其实很简单。5. 典型的坑与排查路径从微信回调到数据库死锁5.1 微信小程序登录态和 openid 的坑现象本地调试时登录成功但过一会儿所有带登录态的请求都返回401或token 失效。原因微信小程序端的wx.login()生成的code是一次性的后端换取openid后如果前端在小程序启动时重复调用wx.login()会刷新 code 并让旧 code 失效更常见的是 token 过期时间设置太短比如 30 分钟用户停在页面上超过这个时间再操作就失效。解决前端把token存到wx.setStorageSync后端把token过期时间设为 24 小时并在每次请求前做一次无状态的 JWT 校验小程序端加一个“登录态失效后自动重新登录”的拦截逻辑不要只在失败时弹个框让用户手动退出。5.2 “请求被拒”的四种常见原因现象小程序端请求后端接口返回request:fail或者statusCode 404/500后端日志里却没有任何相关记录。原因第一baseUrl写错比如漏了端口号第二开发者工具勾选了校验合法域名但本地地址是http被拦下第三后端没开跨域浏览器和微信小程序的请求被同源策略拦截第四真机预览时手机访问的是localhost而localhost指向手机本身而不是电脑。解决先用电脑浏览器直接访问http://localhost:8080/api/health确认后端在线后端用拦截器对/api/**统一加Access-Control-Allow-Origin真机调试时把baseUrl改成电脑的局域网 IP并且确保手机和电脑在同一 Wi-Fi。这里有个血泪经验改完配置一定要“重新编译小程序 重启后端”微信开发者工具经常缓存旧配置改完不重启就继续报一样的错特别容易让人误判。5.3 车位状态并发更新时出现的“幽灵占用”现象两个账号同时占同一个车位两个都提示成功车位列表显示被同一个车牌占用但订单列表里却只有一条记录。原因后端代码是“先select判断状态再update改状态”两个请求同时通过select时都读到status0于是都进入update数据库没有做原子性的状态变更。解决把判断和更新合并到一条 SQLUPDATE parking_space SET status 1 WHERE id #{spaceId} AND status 0后端检查int rows spaceMapper.occupySpace(spaceId); if (rows 0) { throw new BizException(车位已被占用); }。这样无论多少请求同时进来数据库行锁保证只有一条UPDATE会影响行数其他请求拿到 0 行就会走失败分支。注意不要在事务里长时间持锁后再去查其他表否则并发高时会出现数据库锁等待超时。5.4 数据库字符集导致的“中文乱码”现象后台录入的车位区域显示为??小程序的用户昵称变成问号。原因建表时字符集用了latin1或者连接串里没有指定characterEncodingutf8。解决统一把库、表、连接串三者都改成utf8mb4。贴一段检查用的 SQLSHOW CREATE TABLE parking_space; ALTER TABLE parking_space CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;同时确保application.yml里的连接串带了useUnicodetruecharacterEncodingutf8。改成之后最好把表里的脏数据清掉重新插入因为ALTER TABLE不会自动把已经存成乱码的数据修复过来。5.5 说明文档与代码对不上的坑现象阅读源码里的说明文档发现文档里的接口路径、字段名和代码不一致按文档调用接口直接 404。原因毕业设计源码包里的文档常常是从旧版系统复制过来的代码改了一版文档没跟上或者文档只写了核心流程没有覆盖异常分支。解决拿到源码先以代码为准不要以文档为准。先启动后端把带RequestMapping的接口路径全部列出来然后用 Postman 或 curl 逐个问一遍把文档和实际返回有差异的地方用批注标出来。答辩时主动说“我核对过文档与代码并修正了哪些差异”这是一个非常加分的细节。6. 验证系统能不能交三类测试与压测入门毕业设计不是“能跑就行”验收时老师会现场点几个功能甚至模拟并发操作所以最后的验证要覆盖接口层、小程序端和并发场景三层。接口层用 curl 做冒烟测试最直接。以下三个命令分别验证登录、查车位、创建订单这三个最核心链路# 获取 token假设登录接口需要 code这里用固定值模拟 curl -X POST http://localhost:8080/api/user/login \ -H Content-Type: application/json \ -d {code:test_code_001} # 带 token 查询车位列表 curl http://localhost:8080/api/space/list \ -H Authorization: Bearer token # 提交占位订单 curl -X POST http://localhost:8080/api/order/create \ -H Authorization: Bearer token \ -H Content-Type: application/json \ -d {spaceId:1,carId:1}这三个命令能通过的接口层的主链路就没有大问题。如果某个命令返回了 500直接用返回里的异常信息定位不要拿页面反复点。小程序端手测要按“里程碑”来登录、选车位、提交订单、查看订单详情、支付、余额扣减、余额不足提示、车牌绑定、车位状态刷新。每一步不仅仅是“看起来正常”还要在开发者工具的 Network 面板里核对请求参数和后端返回。我见过最典型的手测错误是界面显示“预约成功”但后端 MySQL 里根本没有新订单原因是前端只调了模拟接口没有调真实接口这种问题验收时一查数据库立刻穿帮。并发验证用 JMeter。创建一个线程组设置 100 个线程同时请求“占位接口”观察返回里有多少成功、多少失败“车位已被占用”的数量加起来应当和车位总数一致且订单表和车位状态保持匹配。这个测试同时还能检验数据库连接池配置是否够用如果 100 个请求里有大量超时优先检查spring.datasource的连接池上限和max-wait参数。验证之外再分享一个省钱技巧这类“用户端小程序 管理端看板”的结构不止能用于停车场稍作改动能复用在球鞋寄存、会议室预约、实验室机位管理这些预约类场景。如果你想基于这套方案做二次开发不要动核心的订单和资源状态表只换掉页面文案和计费规则即可。我自己就是这么做的把一次停车场的毕业设计改造成内部会议室预约工具只花了三天核心的占位、取消、超时释放逻辑一行没改。这是这套编程模型最值得投入的地方——它不是一次性的作业而是一套可以反复套用的预约业务骨架。希望这个方向的分析能帮到你。如果你正在调联调或者改表结构先按第 4 章的最小路径跑通再碰并发和支付那些“玄学报错”八成是域名、地址、缓存三件事没理清。本文还有配套的精品资源点击获取