简介：面向微信小程序开发者、毕业设计学生以及需要快速搭建停车场管理示例的前端学习者，项目以停车场系统为核心业务场景，完整呈现小程序端的页面划分与交互流程，标签方向覆盖微信小程序、Java 源码与毕业设计。包内共 393 个文件，压缩包约 4.11MB；其中 172 个 png 图片负责车位及界面视觉素材，55 个 json 文件用于配置与静态数据，52 个 js 文件承载页面逻辑，35 个 wxss 与 31 个 wxml 分别完成样式和页面骨架，另有 vue、map、css 等文件辅助，整体属于混合型小程序前端工程。从预览中的关键入口文件命名可判断，代码已形成相对完整的前端运行链路，适合对照学习 uni-app 编译产物与小程序工程结构。已有 468 人浏览学习，资源体量轻量、目录清晰，便于按页面、配置、逻辑三个层面快速拆解停车场小程序的实现思路。
1. 停车场系统微信小程序源码.rar：这不是解压就能跑的东西，拿到手先做三件事
收到停车场系统微信小程序源码压缩包的开发者，通常已经走完解压这一步，然后在微信开发者工具里卡住。打开小程序目录，页面倒是能渲染，但查不到车位、付不了款，第一反应是"源码是不是缺东西"。其实源码不缺，缺的是把它跑起来的四段链路：小程序端负责页面交互，后端接口负责计费和下单，数据库存放车位与订单，微信平台负责登录和支付。任何一段没有接上，界面就是空壳。本文按解压、配置、联调、上线的顺序，把这四段串起来，让它在本地完整跑通查余位、注册、缴费、离场的闭环。适合刚接手这套源码的开发者，也适合准备用小程序做小区或园区停车缴费方案的从业者。
2. 解压之后先认目录：这份源码包里的前端、后端和数据库脚本各管什么
2.1 miniapp、server、sql 三块目录怎么分工：别把后端代码传进小程序里
拿到压缩包，第一步不是双击微信开发者工具，而是先在文件管理器里看清顶层结构。这类停车场小程序源码的常见布局是：一个目录放小程序前端，一个目录放后端服务，再加一个目录放数据库初始化脚本。先把每个目录的职责分清，后面定位问题才不慌。
parking-miniapp/ ├── miniapp/ # 小程序前端：页面、交互、请求封装 │ ├── pages/ # 首页、车位列表、订单页、个人中心 │ ├── utils/ # 请求封装、日期处理、金额格式化 │ └── app.js # 小程序入口，全局登录态 ├── server/ # 后端接口服务：业务逻辑、支付回调、计费 │ ├── src/ # 路由与处理函数 │ ├── package.json # Node.js 版依赖；Java 版可能是 pom.xml │ └── config/ # 数据库连接、支付参数、密钥 ├── sql/ # 数据库初始化脚本，建表 └── docs/ # 部署文档、接口说明很多人在这里犯第一个错：把整个 park-miniapp 目录导入开发者工具，结果提示找不到 app.json。开发者工具要求打开的是miniapp这个子目录，因为它里面才有app.json、app.js和pages/。后端代码不需要出现在小程序工程里，它只通过 HTTP 接口和前端对话。
后端目录里，config文件是最先要看的东西。数据库账号密码、支付商户号、回调地址全在这里，本地联调时大概率要全部改掉。如果你的压缩包里后端是 Node.js，常见依赖是express加mysql；如果带pom.xml，则是 Java 系，跑法会差一些，后面小节会说明。先掌握分工，再去动配置，整个流程会顺畅很多。
2.2 先建库再起服务，最后开小程序：一套不会写乱的启动顺序
我一般会坚持一个顺序：先让数据库有数据，再让后端接口能响应，最后才打开小程序界面。反过来容易把问题混在一起。数据库里没有表，后端一查就报错；后端没起来，小程序端请求全部超时，分不清是前端 bug 还是后端问题。
mysql -uroot -p < sql/parking.sql这条命令把sql目录下的初始化脚本导入本地 MySQL。脚本里通常包含建库语句和建表语句，比如停车场表、车位表、订单表、价格规则表。导入后可以先用show tables;确认表是否都建好了。常见的坑是本地 MySQL 字符集不是 utf8mb4，导完中文全是问号，建议在建库语句里补充DEFAULT CHARSET=utf8mb4。
后端启动方式取决于源码包里用的技术栈。常见做法是这样：
cd server npm install # Node.js 后端先装依赖 npm run dev # 开发模式启动，默认监听 8080如果后端是 Java 工程，那就不是npm而是mvn spring-boot:run。不管哪种，启动后先验证接口是否活着，用一个最简单的请求确认服务正常，而不是急着打开小程序。验证方式很简单：浏览器直接访问http://127.0.0.1:8080/api/park/list，能返回 JSON 就说明后端和数据库已经通了。这一步通过后，再去配置小程序端，联调时就不用怀疑后端。
3. 微信开发者工具里三处必改参数：AppID、接口地址、不校验域名开关
3.1 AppID：测试号只能看界面，要跑登录与支付必须换成自己的小程序 AppID
源码包自带的 AppID 通常是一个占位符，或者是开发者自己申请时留下的测试号。用这个 ID 能打开页面，但登录流程会报错，因为后端拿这个 AppID 去换 openid 时，微信平台根本不认识。在project.config.json里找到appid字段，换成自己小程序账号的 AppID。
{ "projectname": "parking-miniapp", "appid": "你的小程序AppID", "setting": { "urlCheck": false } }urlCheck: false对应开发者工具里 "不校验合法域名" 的开关，本地联调阶段必须开。如果不开，请求http://192.168.1.100:8080会被微信拦截，报url not in domain list。这个开关只为了方便开发调试，上线前必须关闭并配置正式域名，详见下一节。
还有一个容易忽略的细节：测试号没法调用支付能力。如果要在本地完整跑通支付流程，AppID 必须来自已认证的企业主体小程序，并且开通微信支付商户号。个人主体小程序没有支付权限，这也是源码交付时最常见的落差——界面能看，但钱收不了。
3.2 接口地址 baseUrl：本地联调填局域网 IP，真机不能填 localhost
源码包里接口地址通常写的是http://localhost:8080，这个配置在开发者工具里能跑，因为工具是跑在电脑上的。一旦用手机扫码预览，手机上的localhost指向手机自己，后端接口在电脑上，自然连不上。这里需要把基础地址改成开发电脑的局域网 IP。
// utils/config.js const BASE_URL = 'http://192.168.1.100:8080'; // 本地联调用电脑局域网IP const PAY_CALLBACK = '/api/pay/notify'; // 支付回调路径，上线后要为它配公网域名 module.exports = { BASE_URL, PAY_CALLBACK };改完之后，确认手机和电脑连着同一个路由器。然后打开开发者工具右上角的"预览"，用微信扫码。如果接口仍然request:fail，多半是电脑防火墙拦了 8080 端口，去防火墙设置里放行即可。这一步是踩坑高发区，很多人在这里耗掉半天，实际上只是防火墙没放行。
上线时再把BASE_URL换成正式域名，必须https，而且要在微信公众平台后台配置 request 合法域名。如果不配置，体验版、正式版里所有请求都会被拦截，只有开发者工具能正常，这也是最常见的"本地能跑、上线就挂"的原因之一。
3.3 先跑通最小链路：查车位、下单、支付回调，再开始改界面
改完三处参数，不要急着调 UI，先跑通一条最核心的业务链路。这套链路是：微信登录 → 查车位余位 → 创建订单 → 微信支付 → 支付回调更新订单状态。我用一个简单的请求封装来演示这是怎么串起来的：
// utils/request.js const config = require('./config'); function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: config.BASE_URL + path, method, data, header: { 'content-type': 'application/json' }, success: (res) => { if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data); } else { reject(res.data); } }, fail: reject }); }); } module.exports = request;request封装统一处理了路径拼接、请求头和响应结构。这里默认后端返回格式是{ code: 0, data: ... }，如果你的源码包后端用的是{ success: true }这类结构，要同步调整判断逻辑。
验证链路按下面几步走：
- 在小程序里触发登录，确认后端能拿到
code并返回openid，这一步失败多半是 AppID 和密钥没配对。 - 打开停车场列表页，看余位数是否来自接口，而不是写死的假数据。
- 选车位下单，拉起微信支付，确认支付成功后订单状态从"待支付"变成"已支付"。
- 模拟入场和离场，看计费结果是否正确，订单最终变成"已完成"。
这四步走完，才算真正把源码跑通。之后再改页面样式、加会员功能，都只是增量工作。
4. 后端接口拆解：计费、余位扣减、订单状态机是这套源码的灵魂
4.1 计费放服务端：客户端改了时间就能免费停车，所以别信前端传过来的金额
停车场小程序最容易出事故的地方就是计费。常见错误是把计费逻辑写在小程序端——入场时间、出场时间、金额都由前端算好了再传给后端。这在演示项目里没问题，但在真实场景下等于告诉用户：改一下手机时间就能免单。正确的做法是后端只认自己记录的入场时间和当前服务器时间，价格规则存在数据库里。
CREATE TABLE price_rule ( id INT PRIMARY KEY, park_id INT NOT NULL, -- 停车场编号 unit_minutes INT NOT NULL, -- 计费单位，比如 15 分钟 unit_price_cents INT NOT NULL, -- 每单位价格，单位是分 max_price_cents INT NOT NULL -- 24小时封顶价，单位是分 );价格表用"分"做单位，不直接用"元"。元转分只需要乘 100，但涉及金额计算时，浮点数会带来诡异误差，而且支付接口要求的金额单位就是分。这里把unit_minutes设为可配置，意味着不同时段、不同停车场可以有不同的计费粒度，不需要改代码。
后端拿到出场时间后，计算逻辑大概是这个样子：
// 计算停车费用，entryTime 和 exitTime 都是后端记录的时间戳 function calcFee(entryTime, exitTime, rule) { const diffMinutes = Math.ceil((exitTime - entryTime) / 60000); const units = Math.ceil(diffMinutes / rule.unit_minutes); const total = units * rule.unit_price_cents; return Math.min(total, rule.max_price_cents); }这里用了两次Math.ceil：第一次把相差毫秒数转成分钟并向上取整，第二次把分钟数按计费单位向上取整。停车不满一个计费单位也要按一个单位收费，向上取整才是真实业务规则。最后再用封顶价兜底，防止长时间停车产生天价费用。改价格、改计费单位都只动数据库，不用动代码，这就是把计费放进服务端的另一个好处。
4.2 余位扣减在并发下会变成负数：条件更新是这里的标准答案
停车场的余位字段，源码里通常写着parking_space.stock。两个用户同时下单抢最后一个车位，如果代码是先查 stock 再判断是否大于 0，最后再更新，那两个人都会看到 stock 等于 1，都会下单成功，最终余位变成 -1。这不是玄学，是并发下的经典竞态问题。
UPDATE parking_space SET stock = stock - 1 WHERE id = ? AND stock > 0;关键在AND stock > 0。数据库行锁保证这条语句在同一时刻只有一个事务能成功执行，当stock为 0 时，第二个事务的影响行数是 0。后端根据影响行数判断是否创建订单：受影响行数为 1，扣减成功，继续创建订单；为 0，说明车位已经没了，直接返回"车位已满"。
// 简易示例：真正实现要在事务里执行 const [result] = await db.query( 'UPDATE parking_space SET stock = stock - 1 WHERE id = ? AND stock > 0', [parkId] ); if (result.affectedRows === 0) { return { code: 40001, msg: '车位已满' }; } // 扣减成功后创建订单、状态置为待支付如果只用 "select 先查一下" 的方式，两个请求几乎同时进来时，查到的情况是一样的，超卖就发生了。这是这套源码里必须修复的底层问题。另外注意，stock字段类型要设为整数，别用decimal，不然会有无意义的精度开销。
4.3 订单状态机：待支付、已支付、已入场到已完成，脏数据都出在状态跳错上
订单表是整套系统里的核心表，字段一般包括order_id、user_openid、plate_number、entry_time、exit_time、amount_cents、status。其中status是出现脏数据的重灾区。没有状态机约束，代码里随便设置状态值，早晚会出现"已完成的订单还能被取消"这种事故。
| 状态值 | 含义 | 允许跳转到 |
|---|---|---|
| 0 | 待支付 | 1、9 |
| 1 | 已支付未入场 | 2、9 |
| 2 | 已入场 | 3 |
| 3 | 已完成 | 无 |
| 9 | 已取消/已退款 | 无 |
状态机的核心原则是单向流转，每一步都必须来自合法的前序状态。订单创建时是 0，支付回调成功后变为 1，扫码入场或设备识别车牌入场后变为 2，离场结算完成变为 3。用户主动取消只能在 0 或 1 状态时发生，变成 9 之后不能再回到正常流程。
实现时可以在后端的更新语句里带上状态条件，比如"从状态 0 更新到状态 1"必须写成：
UPDATE parking_order SET status = 1, pay_time = NOW() WHERE order_id = ? AND status = 0;这和余位扣减是同一个思路：用条件更新代替先查后改。支付回调可能重复通知，微信支付会多次推送同一个结果，如果这里不判断状态，同一个订单会被"已支付"刷两遍，金额状态就乱了。这样的更新语句天然幂等，第二次执行时影响行数为 0，不会重复入账，脏数据自然杜绝。
5. 避坑：停车场小程序从源码到上线最常见的 5 个翻车点
5.1 真机预览接口全挂：问题多半出在局域网 IP 与防火墙
现象：开发者工具里一切正常，用手机扫码预览后，列表页空白，请求报request:fail。
原因：源码里接口地址写的是localhost或127.0.0.1。真机上这两个地址指向手机自己，接口实际跑在开发电脑上，手机根本连不上。
解决：把前端config.js里的BASE_URL改成电脑局域网 IP，例如http://192.168.1.100:8080。改完后手机和电脑必须连同一个路由器，同时检查电脑防火墙是否拦截了 8080 端口。放行端口后再预览，基本能通。
5.2 支付成功但订单没刷新：回调地址成了黑匣子
现象：微信里钱已经扣了，小程序端订单状态一直停在"待支付"。
原因：支付回调地址配的是http://localhost:8080/api/pay/notify。微信支付服务器远在云端，它访问不了你电脑上的localhost。
解决：开发阶段用内网穿透工具把本地端口映射成一个公网地址，再把回调地址配成这个地址。上线后回调地址必须是公网 HTTPS 域名。同时在代码里对回调请求做签名校验，别只校验一次就放行，防止伪造回调。
5.3 余位被扣成负数：高峰期抢最后一个车位时的并发事故
现象：活动期间大量用户同时下单，运营后台看到余位变成 -1、-2。
原因：后端用了"先查询余位，再判断，再更新"的逻辑。两个请求同时查到余位为 1，各自都认为自己抢到了，最后执行两次扣减，余位变成负数。
解决：换成条件更新语句，UPDATE parking_space SET stock = stock - 1 WHERE id = ? AND stock > 0，影响行数为 0 就返回"车位已满"。这是最直接有效的修法，不用引入分布式锁，停车场的单点并发量完全够用。
5.4 订阅消息发不出去：一次性模板用一次少一次
现象：代码里调用了wx.requestSubscribeMessage，用户也点了允许，但订单状态变化后消息就是收不到。
原因：小程序的订阅消息分"一次性"和"长期性"两种。源码里用的多半是一次性模板，每让用户授权一次，只允许给该用户发送一条对应模板的消息。开发工具里测试时感觉正常，上线后多条消息围着同一个授权来回用，第二条开始就发不出去了。
解决：入场通知和离场缴费通知拆成两个模板，一条消息对应一次授权。用户确认下单时请求订阅离场通知，入场时再请求订阅入场通知，不要试图用一次授权顶多条消息。
5.5 源码里带着测试商户号和密钥：上线前必须全局替换
现象：换了自己的微信支付商户号后，支付请求一直报签名错误，或者支付金额被扣到了一个完全没见过的商户名下。
原因：交付源码包通常带着某套测试环境的商户号、AppID、小程序密钥。这些配置散落在后端config文件、前端project.config.json甚至写死的代码里。测试环境能跑，不代表你的账号能用。
解决：全局搜索代码里的appid、mch_id、apiv3_key等关键词，全部替换成自己申请的值。重点是把密钥放进环境变量或部署平台的安全配置里，别跟着源码走。替换完再走一遍支付流程，确认回调、退款正常。
6. 进阶：给这套小程序接车牌识别和离场消息，才算真正能营业
6.1 车牌识别回调：让车进场不靠人工输入
基础版的停车小程序，入场时往往靠人工选车位或手动输入车牌。要提高可用性，常见做法是接入停车硬件厂商的车牌识别回调。摄像头识别到车牌后，硬件平台把车牌号推送到后端接口，后端自动关联用户会员或创建临时订单：
// 设备回调入口：硬件识别到车牌后调用这个接口 app.post('/api/park/entry', (req, res) => { const { plateNumber, deviceId, ts } = req.body; if (!plateNumber) return res.status(400).json({ code: 40001, msg: '缺少车牌号' }); const order = createOrderByPlate(plateNumber, deviceId, ts); res.json({ code: 0, orderId: order.id, status: order.status }); });这套回调逻辑不用改小程序端，后端收到车牌后创建订单，状态直接置为"已入场"。用户在小程序里绑定车牌，离场时自动匹配订单，再走支付流程。接入前先确认硬件厂商的回调协议是 JSON 还是 form 表单，字段名能不能改，不然对接时得做一层适配。
6.2 离场消息：用订阅消息把缴费引导推到用户手机上
用户即将离场时，系统可以推送一条缴费提醒。这部分要用订阅消息，但注意一次性模板的限制。我通常的做法是用户在支付成功页主动点击"接收离场提醒"按钮后再发起订阅授权，这样语义明确，用户也知道会收到什么。每次授权只发送一次离场通知，订单完成后这个授权就失效了，下次停车需要重新授权。
后端推送失败时要看错误码，重点区分"用户未授权"和"模板无效"两类原因。前者要优化引导时机，后者要检查模板 ID 是否匹配当前小程序类目。我把这条当作习惯沉淀下来：拿到任何带支付和通知的源码，先分别验证支付回调、订阅消息、条件更新这三个块，再往界面上加东西。这三块是停车场小程序的命门，表面上跑通一遍，后面能省下大量排查时间。这也是我希望每个接手这份源码的开发者最先建立的意识。希望帮到你。
本文还有配套的精品资源，点击获取
