1. 项目定位与整体设计思路
这个项目做下来，最直观的感受是：选框架不难，难的是想清楚每一层到底该由谁负责。
标题里同时出现了 ThinkPHP 和 Laravel，其实是在暗示一件事：这个停车场管理系统要具备双端适配的能力——服务端既能跑在 ThinkPHP 上（国内很多学校、企业的服务器环境对 ThinkPHP 有历史依赖），又能平滑迁移到 Laravel 上（更现代的语法、更规范的生态）。而前端则统一由微信小程序承载，用户扫码即用，不需要安装 App。
一句话概括整个项目的本质：它是一个“小程序做界面、后端管数据、停车场设备做执行”的三层联动系统。用户在小程序里查车位、预约、缴费、开闸，管理员在小程序里看营收、管月卡、处理异常，设备端接收指令完成抬杆放行。
这套系统要解决的，绝不是“做一个能显示剩余车位的小程序”这么简单。真正核心的矛盾有三个：车位数量的实时一致性、订单与支付状态的强一致、多端并发下的数据竞争。举个实际例子，早晚高峰期，同一个车位可能被两个用户同时点击预约，如果后端不做幂等处理，就会出现“两个人抢到同一个车位”的事故。
所以在架构设计上，我一开始就没有走“ThinkPHP 写一套、Laravel 再写一套”的双份代码路线，而是把业务逻辑全部收敛到服务层，框架层只做路由、中间件、数据库连接这些基础设施。这样换框架的时候，业务代码改动量控制在 10% 以内，只需要适配框架的请求注入方式和数据库操作 API 即可。
再说说为什么选择微信小程序而不是 H5 或者原生 App：
- 获客成本低：微信扫一扫直接打开，不需要应用商店审核，停车场门口贴个码就能用。
- 支付链路完整：微信支付本来就是小程序生态的一部分，预下单、回调、退款都有现成的 API，不用自己对接第三方支付。
- 入场体验好：小程序可以主动获取地理位置，用户快到停车场门口时自动弹出“即将入场”提示，这种体验是 H5 做不到的。
至于为什么需要同时兼容 ThinkPHP 和 Laravel，这个我在后面的章节专门展开。这里先明确一个大原则：框架永远是工具，业务模型才是项目的地基。
2. 为什么同时兼容 ThinkPHP 和 Laravel
很多同学会问：项目里选一个框架不就行了吗，为什么要两个都支持？这个问题的答案，其实藏在真实项目的部署环境和团队协作方式里。
2.1 ThinkPHP 的现状与适用场景
ThinkPHP 在国内的存量项目非常多，尤其是 2015 年到 2020 年之间搭建的校园系统、政务系统、中小型企业管理系统，很多跑的还是 ThinkPHP 3.x 或 5.x。这些系统的共同特点是：不追求极致的代码优雅度，但要求部署简单、运维门槛低。
ThinkPHP 的优点是上手快、文档全是中文、IDE 提示友好，而且对虚拟主机、低版本 PHP 环境的兼容性做得很好。很多老服务器跑着 PHP 5.6 或者 PHP 7.0，装不了 Laravel 要求的 PHP 8.x 环境，这时候 ThinkPHP 就是唯一选择。
这次项目的实际背景是：停车场的上级管理单位用的是老旧的 ThinkPHP 系统，内部数据接口都是老接口格式。如果我用 Laravel 完全重写，数据对接的成本就会非常高，甚至要动他们的老数据库结构。所以最稳妥的方案是：新开发的停车场小程序后端用 Laravel 写核心逻辑，但数据接口层保留 ThinkPHP 风格的返回格式，这样老系统升级的时候，前端小程序不需要做任何改动。
2.2 Laravel 的优势与迁移成本
Laravel 在国内流行起来之后，最大的贡献是带来了更规范的 MVC 分层、中间件机制、以及 Composer 包管理。如果用 Laravel 来写停车场系统，有几个非常明显的优势：
- 队列系统自带：ThinkPHP 里处理“入场通知”“出场结算”这类异步任务，需要自己用 crontab 去拉，而 Laravel 的 Queue 可以直接驱动 Redis，配合定时任务调度，代码写起来很舒服。
- Eloquent ORM 方便关联查询：停车场系统里车辆、订单、月卡、管理员、设备这些模型之间关系复杂，用 Eloquent 的 with 预加载可以少写很多 SQL。
- 中间件做权限控制很顺手：小程序端和管理端共用一套后台，通过 API 返回状态码来区分角色。Laravel 的中间件可以把这种逻辑放在最外层，而不是在每个 Controller 里重复写。
但是 Laravel 不是没有缺点。它的学习曲线比 ThinkPHP 陡峭得多，“门面”这个概念就劝退了很多人。而且 Laravel 的 Composer 依赖太重，一个空项目搭起来就是 30 多 MB，放在不规范的服务器上还容易出现权限问题。
2.3 双框架兼容的架构思路
我在项目里实际上做的是“逻辑层双实现，接口层单标准”：
| 层级 | ThinkPHP 版本 | Laravel 版本 |
|---|---|---|
| 路由 | Route::rule | Route::apiResource |
| 请求注入 | $request 对象直接获取 | Request 依赖注入 |
| 数据库 | Db::name('table') | Model::query() |
| 业务服务 | 独立 Service 类 | 与 ThinkPHP 共用 Service 类 |
| API 返回 | 统一 JSON 结构 | 统一 JSON 结构 |
我抽出来的公共部分，是一个独立的 Service 层，里面放的是停车场业务的核心逻辑：车位的状态机流转、订单的生成与超时关闭、月卡的有效期计算、设备指令的发送队列。这一层完全不感知框架的存在，只输入业务参数，输出标准结果。然后在不用的框架里写一个薄薄的 Controller，把框架里的 Request 对象转换成 Service 的入参。
这样做的好处显而易见：换框架不影响业务。团队里有人喜欢 Laravel，有人习惯 ThinkPHP，大家可以在不同的分支上写各自风格的 Controller，核心 Service 代码统一评审、统一维护。对项目交付来说，也保住了“能在老环境跑，也能在新环境跑”的承诺。
3. 微信小程序端的功能设计与页面拆解
小程序端是这个系统的“门面”，用户看到的每一个按钮、每一个页面，背后都对应着后端的复杂逻辑。我在设计页面结构的时候，遵循一条原则：用户能少点一次就少点一次，能自动获取的信息绝不让人手动填。
3.1 顶部导航栏与交互适配
小程序里第一个容易踩坑的地方是顶部导航栏的适配。不同的手机型号，状态栏高度不一样。iPhone 有刘海屏，Android 各家厂商的挖孔屏位置也各不相同。如果导航栏高度写死，小程序在非标准屏上就会出现按钮被刘海挡住的情况。
做法是用 wx.getSystemInfoSync() 获取 statusBarHeight，然后动态计算导航栏高度。核心代码如下：
const getNavBarHeight = () => { const systemInfo = wx.getSystemInfoSync() const menuButtonInfo = wx.getMenuButtonBoundingClientRect() const navBarHeight = (menuButtonInfo.top - systemInfo.statusBarHeight) * 2 + menuButtonInfo.height return { statusBarHeight: systemInfo.statusBarHeight, navBarHeight, menuButtonInfo } }把这段逻辑抽成一个公共的组件，在页面 JSON 里配置 usingComponents 引入，所有页面的顶部栏就统一了。要特别注意：自定义导航栏必须在页面级配置 navigationStyle: custom，否则会出现双标题栏的尴尬。
3.2 页面列表加载更多与性能优化
停车场的车位列表、订单列表、缴费记录，这三个核心列表全部走“分页加载更多”的交互模式。微信小程序 setData 的性能瓶颈在数据量大的时候非常明显，所以列表数据我做了三层优化：
第一层是后端分页，每一页固定返回 10 条数据，用 id 做游标而不是 limit 偏移。原因很简单：limit 偏移在数据量大时越翻越慢，而游标方式不管翻到第几页，查询速度都恒定。
第二层是前端缓存，已经加载过的页面数据存到 data 对象里，下拉触底时只拼接新数据，不做全量重新渲染。
第三层是节流控制，防止用户在快速滑动时连续触发触底事件。实现方式是做一个 loadingRef 标志位，一次请求未返回前不再发下一次请求：
onReachBottom() { if (this.data.loading || this.data.isEnd) return this.setData({ loading: true }) wx.request({ url: `${API_BASE}/api/parking/list`, data: { cursor: this.data.nextCursor, pageSize: 10 }, success: (res) => { const { list, nextCursor, isEnd } = res.data this.setData({ list: this.data.list.concat(list), nextCursor, isEnd, loading: false }) } }) }这个“加载更多”交互看似简单，但实际上有非常多的细节。列表项尽量用纯文本和简单的 flex 布局，不要在小程序列表里塞地图组件或原生 canvas，否则滚动帧率直接掉到 30 帧以下。
3.3 单选框与表单组件的业务落地
预约车位的页面里，用户要选择“停车时长”和“车型”，这两个都是单选场景。微信小程序的 radio 组件原生样式比较简陋，直接用在业务页面里会显得很“官方”。我选择用自绘的选中卡片来替代原生控件：外观上是一张圆角卡片，右侧有个自定义的圆形选中标识，选中时显示绿色实心圆点，未选中时显示灰色描边圆。
这个方案比原生 radio 好在两点：视觉效果统一、可定制性强。点击事件的处理逻辑就是维护一个当前选中的 index，每个卡片绑定的><view class="duration-item {{selectedDuration === item.value ? 'active' : ''}}" wx:for="{{durationList}}" wx:key="value" >wx.startBluetoothDevicesDiscovery({ services: [], allowDuplicatesKey: false, success: () => { wx.onBluetoothDeviceFound((res) => { const devices = res.devices || [] devices.forEach((device) => { const rssi = device.RSSI const distance = Math.pow(10, (rssi - calibration) / (-10 * n)) // 根据距离更新定位结果 this.updateLocation(device.localName, distance) }) }) } })
这里的calibration取值是信标在 1 米处的接收信号强度，n是环境衰减因子，一般取 2-3。这些参数我在部署时用真实设备做了校准，否则蓝牙定位误差会非常大。
4. 后端核心模块设计与实现
后端是整套系统的大脑，承载着车辆进出、订单管理、支付、月卡管理、设备控制等核心业务。我在设计中重点抓了两块：强一致性的订单状态机和设备指令的可靠下发。
4.1 数据库设计
先看核心表结构设计。停车场系统里最重要的三张表是车辆表、车位表、订单表。
车位表要区分车位类型（普通、充电桩、无障碍），停车场的物理楼层和区域编号，状态字段表示空闲、预占、占用、维修。这张表需要冗余一个 area_name 字段，避免频繁关联区域表。
订单表是所有业务流转的核心，字段包括订单号、车牌号、入场时间、出场时间、费用、支付状态等。为了应对高并发下的订单生成，订单号我用“日期 + 随机数 + 车辆 ID”的拼接方式，单独用时间戳做主键会遇到并发冲突。
月卡是停车场稳定收入的重要来源。月卡表除了绑定车牌号外，还绑定车主的 OpenID，这样小程序端可以展示用户的月卡状态，并支持在线续费。
4.2 停车流程的状态机设计
车辆进出停车场不必简单地在数据库里改一个状态值，需要一套严格的状态机流转来防止混乱。
整个流程分为四个节点：
- 用户在小程序端预约车位，小程序把车辆信息和车位 ID 发送给后端，后端创建一个预约订单，车位状态改成“预占”。
- 车辆入场时，停车场入口摄像头识别到车牌，后端查找预约订单，核对车牌，车位状态改成“占用”，预约订单变成“进行中”的入场记录。
- 车辆出场时，出口摄像头识别车牌，后端计算停车时长和费用，生成待支付订单。
- 用户在小程序里完成支付，订单状态变成“已完成”，车位状态改回“空闲”。
这套流转的基础是一个 order_status 字段，数组分别是 1、2、3、4，各自代表预约中、进行中、待支付、已支付。所有更新操作都在数据库事务里执行，锁表操作放在车位表级别，避免并发冲突。
4.3 定时任务与订单超时处理
预约之后用户可能十秒内又被别的事情打断，这时如果预约订单一直挂着，车位就被占死了。我的方案是：预约订单超过十分钟未入场，自动释放占用的车位，同时发一条模板消息给用户，说明预约已超时失效。
这个功能在 Laravel 里用 schedule 调度，在 ThinkPHP 里用 crontab 调入口文件。因为两个框架的时钟任务入口不一样，我把“检查超时订单并释放车位”的逻辑写成一个 Job 类，两边各写一个定时任务控制器来触发同一个 Job。这样就保证了双框架下业务的一致性。
4.4 环境与依赖选择
这个项目的后端环境我推荐使用 PHP 7.4 或者 PHP 8.0。ThinkPHP 5.1 对 PHP 7.4 兼容很好，Laravel 8 则要求 PHP 7.3 以上，两个要求正好落在 7.4-8.0 区间。Redis 用作缓存，存储热门车位的状态快照，减少对 MySQL 的高频查询。
如果觉得单独买一台服务器成本高，可以在一台 2C4G 的云主机上同时部署两个框架，域名通过 Nginx 的 location 规则区分 path 前缀：/tp 走 ThinkPHP，/laravel 走 Laravel。这样部署的好处是，一个环境可以直接对比验证两套代码逻辑的一致性。
5. 高频功能模块实战：监控抓包、插件限制与打包投用
这一部分要讲的是真正“上线前被折磨得最惨”的功能环节。我敢说，小程序停车场系统的开发中 70% 的调试时间耗在了这几个位置上。
5.1 使用 Charles 抓包调试微信小程序
微信小程序的网络请求无法直接在 Web 开发工具里看到完整的 Header 和底层链路细节。为了排查支付回调、地图接口返回数据是否正确，我使用 Charles 进行本地 HTTPS 抓包。
步骤概括：
- 下载安装 Charles，在 Proxy 菜单里打开 SSL Proxying，开启 443 端口。
- 电脑和手机连接同一个局域网，手机设置代理为电脑 IP 和 Charles 的默认抓包端口 8888。
- 在手机上访问 chls.pro/ssl 下载并安装 Charles 的 SSL 证书。
- 在微信开发者工具里，把请求代理指向本机的 Charles 端口。
Charles 抓包时我最常看的是“JSON 响应”面板，直接排版好 JSON 数据，不必逐行看原始 header。如果发现 wx.request 在正式环境出现跨域问题，通常先查 Charles 里的请求信息，能快速定位是域名没有配置合法域名还是后端没有关闭 CORS。
5.2 Interface 限制与插件使用
不少同学反馈，小程序端打包或者真机运行时提示“第三方插件未授权”或“找不到插件”。这次项目里用到了天地图插件，必须在小程序管理后台的“设置-第三方设置-插件管理”里搜索并添加插件 AppID，然后在 app.json 里声明和版本号：
"plugins": { "tiandituPlugin": { "version": "1.0.0", "provider": "wx3d4......" } }这个插件在开发工具里表现正常，但真机预览时会报“invalid plugin version”，大概率是发布时插件版本号和线上版本不一致。修复办法是先清除插件缓存，重新声明版本后再编译。
还有一类高频报错是wx.getSystemInfoSync在低版本基础库被废弃，建议使用wx.getWindowInfo替代。在做顶部导航栏适配时，我踩过这个坑，适配代码在开发者工具没问题，但安卓低版本手机上标题栏高度直接不对了。
5.3 微信开发者工具的项目运行与试用分发
开发调试好之后，准备把小程序发给停车场的运维同事试用。微信开发者工具提供“预览”功能，点完会生成一个二维码，用微信扫码即可打开真机预览版。
这里有一个限制：预览二维码默认有效期 15 分钟，超过了需要重新生成。测试团队如果分散在不同地方，可以上传代码到微信后台“体验版管理”，生成长期有效的体验二维码。体验版比预览版稳得多，但体验版限制最多 15 个微信号绑定，需要在小程序管理后台设置“成员管理”并添加体验成员。
整体试跑阶段，我把“线上 Bug 反馈”整理成了一个腾讯问卷，扫码进入小程序后点击“问题反馈”，填写截图的设备和操作路径。收集了大约一周反馈后，修复了三四个只有真机才会有的兼容性 bug，比如部分安卓手机蓝牙扫描不到信标，原因是allowDuplicatesKey参数设置错误。
5.4 uniapp 打包微信小程序与体积限制
如果团队不是只做微信端，还要兼顾未来做支付宝小程序或 App，用 uniapp 开发再打包为微信小程序就是更优的方案。uniapp 的好处是一套 Vue 代码，同时编译输出到微信、支付宝、H5 多端。
但 uniapp 打包会遭遇一个很实际的问题：编译后体积超限。微信小程序规定主包加插件的总代码包大小不能超过 2MB，一旦超过就会报错：
Source size 2612kb exceed max limit 2mb
这个报错我处理过多次，解决方式是分包加载。把所有页面分为“主包”和“分包”两个目录，登录、首页、车位搜索这些最常用的页面放主包，支付结果、月卡购买、历史记录等低频页面放分包。同时开启了 uni_modules 的按需引入，不要一次性把插件库全部打包进去。
分包配置示例：
// manifest.json 中的 mp-weixin 配置 "mp-weixin": { "optimization": { "subpackages": true }, "subPackages": [ { "root": "pages/order", "pages": ["pay-result", "order-detail"] }, { "root": "pages/my", "pages": ["month-card", "history"] } ] }这样主包就能控制在 1.5MB 以内，线上加载速度明显提升。如果你的项目里引用了地图组件又加入了图表库，体积超限基本是必然的，一定要从开发的一开始就规划好分包结构。
6. 场景落地：食堂订餐、社区团购与家政服务的方法复用
这项目虽然叫停车场管理系统，但我在微信小程序领域积累的一些方法论，如果直接迁移到其他行业小程序（校园食堂订餐、社区团购、家政服务），同样有一套成熟的路径。很多同类型项目的后端架构和交易链路其实是相似的，核心差异在领域建模上。
6.1 校园食堂订餐系统的现状与研究
“基于微信小程序的校园食堂订餐系统”这类题目在毕业设计需求里出现得非常高频。它的本质就是一个小范围内的电商交易：用户浏览菜品、下单、支付、取餐。国内现状是很多高校后勤系统老旧，线下的排队拥堵严重，小程序订餐能缓解这个问题，但真正落地时卡在“食堂窗口的出餐状态同步”。
停车场系统的状态机思想在这里可以复刻：订餐订单同样需要“待支付、已支付、制作中、待取餐、已完成”状态。出餐状态的推送依赖后端主动通知，可以用微信订阅消息实现。
我在一个校园项目的实践中遇到的最大坑是：食堂后厨的终端没有联网，出餐状态只能靠人手动点击“完成出餐”。这对应到停车场项目里，相当于出口道闸没有自动识别信号，需要人工确认才抬杆。解决办法就是把“人工确认”做成一个极简的点击按钮，把操作摩擦降到最低。
6.2 社区团购的商品列表与拼单逻辑
社区团购系统的核心是无库存销售和团长分佣。小程序端需要展示团长的自提点列表、发布的开团信息、用户的参团订单。车辆管理系统的车位列表分页“加载更多”逻辑可以直接复用，团购商品列表也一样，只不过游标字段从车位 id 改成商品 id。
拼单逻辑的关键在“成团”判定。如果两个用户同时参与同一团购，需要保证剩余成团名额不超卖。这里我在停车场项目里用的“Redis 原子减库存”方案可以直接搬过来：
$remaining = Redis::decr('group_buy_stock:' . $groupId) if ($remaining < 0) { Redis::incr('group_buy_stock:' . $groupId) return $this->error('名额已满') }注意这里的 decr 和判断必须在一个原子操作链路里完成，不然会有超卖风险。这个方案比数据库行锁高效得多，吞吐量足够支撑社区团购的高峰并发。
6.3 家政服务系统的订单撮合逻辑
家政服务系统和小程序停车场系统的差距更远一些，但订单撮合和派单引擎依然能对得上。停车场需求是“空闲车位推荐给用户”，家政服务需求是“空闲阿姨推荐给雇主的订单”。这个推荐逻辑最朴素的全覆盖实现：
- 后端先找到该区域内上下班通勤时间匹配的阿姨列表。
- 按上次服务后的评价分数排序。
- 如果已选择的阿姨无人接单，系统再推荐第二梯队的阿姨。
这类“按条件过滤加排序分发”的推荐逻辑，本质上与停车场“按距离排序推荐空闲车位”的逻辑没有区别。可以把推荐服务抽象出来，用接口接收泛型的筛选条件，返回候选列表，再由业务层决定如何展示。
7. 常见问题排查与避坑实录
这部分内容来自真实上线运营时踩过的坑，实用性远高于常规 API 文档。
7.1 wx.login 静默登录与登录状态过期
小程序端每次冷启动都会执行 wx.login，拿到临时 code。后端拿去换 openid 和 session_key。要注意的是 code 五分钟有效且只能用一次，如果后端处理失败返回 401，前端立刻再调 wx.login 会拿到新 code，但 old code 已经失效了。处理方案是前端在收到 401 后强制重新登录并重放发失败的请求。
7.2 微信小程序订阅消息授权弹框
订阅消息的授权弹框是用户主动触发才弹的，不能在小程序 onLoad 阶段直接弹。正确姿势是用户在点击“支付”或者“预约成功”按钮时，才调用 wx.requestSubscribeMessage 弹窗。并且一次性订阅只能用一次，如果订单状态变化多次通知用户，需要把一次性订阅做完一次消息消费后再进行下一次的弹窗引导。
7.3 支付回调重复通知
微信支付官方回调为了确保送达，会多次通知。后端必须做幂等校验，在支付成功的回调里先查订单状态，如果已经是“已支付”，直接 return true 不重复处理。
7.4 小程序苹果防截屏
小程序里用户可能涉及隐私信息（比如月卡手机号），如果不想苹果手机截屏保留这些信息，可以用禁止截屏的 API，iOS 上设置wx.setVisualEffectOnCapture，但目前仅在部分 iOS 版本上生效，Android 端没有这么严格的限制。关键信息还是要通过会员密码等措施兜底。
7.5 蓝牙信标校准
一个值得强调的经验是：蓝牙定位的准确性严重依赖现场环境。停车场里的金属柱子、墙壁都会反射和衰减电磁波，同一个信标在节假日车辆较多时的 RSSI 分布和平时完全不同。部署时一定要在多个时段做多次校准，否则误差会达到五米以上。调试时建议把 RSSI 原始数值显示在小程序的隐藏调试面板上，方便现场定位。
| 问题现象 | 可能原因 | 排查方案 |
|---|---|---|
| 地图上标记位置偏移 | 坐标系不一致，GCJ-02 与 WGS-84 混用 | 统一使用腾讯坐标系，转换后再传给 map 组件 |
| 列表滚动卡顿 | setData 传输数据量过大 | 缩小分页 size，优化数据结构，避免冗余字段 |
| 真机预览无数据 | 调试器请求正常但真机屏蔽 | 检查“开发环境不校验域名”选项，去掉后重新请求 |
| 支付成功但订单未更新 | 回调地址被防火墙拦截 | 检查服务器日志，确认微信回调 IP 白名单配置正确 |
| 微信小程序的蓝牙搜不到信标 | 未开启蓝牙权限或没有提供 service UUID | 声明蓝牙权限，设置正确的 service UUID |
8. 个人实操心得与建议
这次项目做下来的最大体会是：停车场小程序不是难在写代码，而是难在把线下流程和线上流程在时间线上完全对齐。
停车场里发生的很多事，比如“车已经开到出口但订单还没支付”“车牌摄像头识别失败”“车主手机没电打不开小程序”，这些都是永远无法用纯代码解决的问题。所以我在系统里预留了一个“微信对讲人工客服”的入口，用户遇到任何异常都可以一键呼叫值班人员。这一设计比多写一百行防御代码都有用。
对于还在犹豫选 ThinkPHP 还是 Laravel 的开发者，我的建议是：能做出取舍就别双框架并行，如果你真的遇到了必须兼容两条技术栈的环境，一定要把业务逻辑从框架依赖里彻底剥离出来。不剥的话，写两套 Controller 的维护成本会超过你省下的所有时间。
最后分享一个实际部署时的小技巧：把车位的动态容量数据用 Redis 缓存，同时在 MySQL 里定期做快照备份。如果缓存意外丢弃，恢复时用快照数据结合订单表重新计算一遍秒级容量。这个兜底机制已经救了我两次事故。任何人做车位状态同步的系统，都建议提前想好这套兜底方案。
