身边开车的人几乎都有过这种经历：在商圈楼下绕了三圈找不到一个空位，好不容易看到入口，进去转半天发现全是内部预留车位；或者临出门发现车上贴着补缴单，才知道自己上次忘了缴费。智慧停车这个概念提了很多年，但真正把它做顺手的落地产品并不多。我最近完整走了一遍“基于微信小程序的智慧停车系统”从设计到落地的过程，从需求梳理、架构选型到小程序前后端联调、设备对接、支付闭环，踩了不少坑，也沉淀了一些可直接复用的经验。这篇文章就把整个设计过程掰开揉碎讲清楚，包括选定微信小程序这个入口的原因、负责核心控制的后端与硬件如何协作、几个关键模块的实现细节，以及上线前一定会遇到的常见问题。对于想用低成本、高效率方式盘活一个车场或者打算做一套可对外输出的方案型产品的开发者，这篇内容应该能帮你少走小半年的弯路。
1. 项目整体设计与业务逻辑梳理
1.1 智慧停车系统到底要解决什么
先别急着看技术，第一步是把业务想明白。一套智慧停车系统的核心战场有两个：给车主找车位、省时间的体验，和给车场运营方增收、降本的效率。
从车主视角，最痛的三个点是入场排队、找位绕圈、出场缴费慢。从运营方视角，最痛的是车位利用率低、收费依赖人工、跑冒滴漏管控不住。所以系统设计的第一步不是画架构图，而是把这两组痛点映射成具体的功能和流程：
- 车主端小程序提供：空闲车位实时查看、车位推荐与导航、车牌绑定、微信支付出场费、电子发票、停车记录查询。
- 管理端提供：车场运营总览、出入记录、营收统计、计费规则配置、异常订单处理、设备状态监控。
这里要说两句实话。很多类似项目一上来就堆人脸识别、无感停车、室内定位，看起来很酷，但落地时设备成本、维护成本和数据准确率三个坎直接击穿预算。我们的原则是先做完基础闭环，把入场、找位、出场、支付这条链路跑顺跑稳，再把所谓“智能”往上叠加。这也是我强烈建议你采用的设计思路。
1.2 核心业务流程拆解
把整个停车行为拆开，核心是四条主线：
入场流程：车到入口，摄像头抓拍车牌 → 云端车牌识别服务返回车牌号 → 后端判断该车是否在系统内（月租车、会员车、临时车）→ 道闸控制器收到开闸指令 → 抬杆放行。系统同步生成一条“入场记录”，计费从这一刻开始算。
找位流程：车主打开小程序，地图上看到车场的实时余位。这里需要说明，数据来源是车场出入口的计数逻辑，而不是每个车位装传感器。出车场总车位数减去入场未出场的车辆数，得到理论余位。有一部分车是内部车不经过入口，所以真实余位通常还需要用出口计数反向修正。
出场流程：车开到出口，摄像头再次抓拍 → 系统匹配入场记录算出费用 → 如果是支付过的车，直接抬杆；没支付的车，现场扫码在微信小程序里查询→ 支付 → 道闸联网确认到账后抬杆。
支付闭环：小程序内唤起微信支付 → 支付成功回调到后端 → 后端更新订单状态并通知道闸放行。这里最关键的是出场的免密支付能力：用户提前在“我的车辆”里绑定车牌并开通代扣，出场时系统检测到已付费自动抬杆，体验接近无感停车。
1.3 为什么一定要选微信小程序而不是App和小程序通用
围绕终端形态我纠结过一阵子。初期考虑做App，停车频率高的车主更值得装App。后来一算账就放弃了：App的下载安装成本太高，推广一个用户装App的成本足够覆盖好几个月的停车费，而且Android和iOS两套兼容、上架审核、版本迭代全是成本。小程序的优势恰好弥补这些：
- 免安装，微信扫一扫直接进，符合停车场“即用即走”的场景特性。
- 微信支付接口成熟，无需重新绑定银行卡，调起支付的成功率高很多。
- 通过服务通知和订阅消息，可以主动向用户推送临停缴费提醒、月租到期提醒，留存率高。
- 开发调试方便，微信开发者工具热更新，不用走应用商店审核周期。
当然小程序也有坑，比如代码包体积限制、部分API受类目和权限限制、有些硬件交互能力弱于原生。但我们这个项目恰好不需要蓝牙协议栈，核心交互都是网络请求，小程序完全够用。这套结论可以直接沿用：除非你的停车场需要深度蓝牙或NFC交互，否则微信小程序就是最优解。
2. 系统架构设计与关键技术选型
2.1 整体架构分层
整套系统按职责分成四层，下面分别是我的选型和理由。
接入层：微信小程序前端。这里我选了原生小程序框架，而不是wxml插件市场里常见的第三方框架。原因是停车小程序页面不多，核心交互是地图、列表、支付，这些用原生开发完全没压力，还能省掉一层编译抽象。如果你团队熟悉Vue，也可以考虑跨端框架，方便以后一把梭出H5版本，但要注意跨端框架有时对微信原生组件的支持有延迟。
网关服务层：后端采用轻量级微服务但不过度拆分。我用的主语言是Java，框架是Spring Boot。整个系统拆了三个服务：
- user-service：用户注册、登录、车牌管理、月卡管理。
- parking-service：车位状态、计费规则、订单生成与结算。
- device-gateway：设备接入，处理道闸控制、车牌识别回调、设备心跳。
三个服务走内部HTTP或消息队列通信，中间加了一层网关做聚合。这样后续增加新的车场、接入新的设备品牌，只需要扩展对应模块，不会牵一发动全身。
基础设施层：MySQL存业务数据（用户、订单、车场、规则），Redis做缓存和分布式锁。车位状态这种高频读写的key直接用Redis的Hash存储，考虑的是余位扣减这种操作要保证原子性，用Redis的Lua脚本做原子减操作非常顺手。运维层面用Docker Compose一键部署，配合nginx做流量入口，三台普通云服务器足够支撑几千个并发。
硬件协同层：停车场出入口的高清识别摄像头、道闸控制器通过TCP长连接或HTTP回调与device-gateway通信。注意道闸控制器的IO信号延迟很关键，网络抖动会导致抬杆延迟，车主体验极差。后来我们优化成设备端本地判断：摄像头识别到车牌后先本地开闸，云端同步记录，开闸快但增加了逃费风险。再加一道风控：如果云端没有查到对应入场记录，系统会截断后续出场。这个权衡要根据场景选，后面细说。
2.2 关键技术选型背后的取舍
选技术栈时我遇到过不少“差不多先生”，最后都有一番取舍，列个表给你参考：
| 技术点 | 方案A | 方案B | 我的选择 | 原因 |
|---|---|---|---|---|
| 前端框架 | 原生小程序 | uni-app | 原生小程序 | 本项目功能简单，原生性能好、排查问题直接 |
| 后端语言 | Java/Spring Boot | Node.js/Express | Spring Boot | 强类型约束、全家桶成熟，适合前后端长期演进 |
| 车位检测 | 地磁传感器 | 视频识别+出入口计数 | 出入口计数 | 成本低、实施快，地磁后期维护费太高 |
| 实时推送 | WebSocket | 轮询 | WebSocket+轮询兜底 | 场景太复杂无法单纯依赖一种 |
| 支付对接 | 微信支付原生 | 聚合支付 | 微信支付原生 | 与小程序天然打通，代扣能力做包月会员很舒服 |
这里面重点说下停车位检测的坑。很多产品经理一上来就提“我要知道每个车位是空的还是占用的”，听起来很合理，但仔细算一下：一个500车位的地下停车场，要全覆盖摄像头或地磁，设备采购与施工的费用就足以压垮预算。我们用的出入口计数方案，只需要两台摄像头加一个计数逻辑，先把车位余量准确性做到85%，剩下的偏差用“近期入场未离场车辆数”和“出口补采修正”来调整表现。这属于“先跑通全业务，再优化体验”的思路，在资源有限的情况下非常务实。
2.3 数据库设计要点
数据库设计直接影响计费准确性和并发性能，这块值得单独拎出来讲。核心表有四张：
车场表（parking_lot）：记录车场基础信息，包括车位总数、开放时间、经纬度、地址、计费规则JSON字段。我特意把计费规则做成JSON而不是关系表拆分，因为计费规则在不同时段、不同类型的车上差异很大，拆开写要联表查询，放JSON里虽然不太“范式”，但是快。
用户表（user）：微信开放ID、手机号、昵称、头像、状态。注意微信登录会有两个ID：openid和unionid，老项目跨平台时unionid常用，但只做小程序端，openid就够了。
车辆表（vehicle）：车牌号、用户ID、车辆类型（临时/月租）、默认标记。这里强烈建议用户绑车牌时做一次校验，调一下车牌识别的结果库，哪怕不做真实验证也能避免极少数恶意乱填。
订单表（parking_order）：车牌号、入场记录ID、入场时间、出场时间、应收金额、实收金额、支付状态、支付时间、流水号。订单表是千万级数据的主战场，按照车场ID和时间段做分表设计要提前做好，否则上线一年后就开始卡顿。
另外一张辅助表是系统参数表（sys_config），统一存诸如“临停免费时长分钟数”、“出场宽限时间秒数”、“免密支付开关”这类配置，避免每次改规则要发版。
关于金额字段，我后来吃过一个闷亏：计费用小数存，导致对账不平。正确做法是金额统一用“分”为单位存整数，订单、账单、报表全部如此，到前端展示再做单位转换。
3. 核心功能模块的设计与实现细节
3.1 车位实时监控与余位计算
余位显示是停车系统最核心的信任点。如果车主在小程序里看到余位是“18”，开到入口发现实际已经满了，体验直接崩塌，以后不会再用了。所以这个模块不只是加法减法，还包括数据修正机制。
数据结构上，用一个Redis key保存当前余位：
parking:{lotId}:available // 类型：int入场时执行Lua脚本：
if redis.call('get', KEYS[1]) == nil then redis.call('set', KEYS[1], ARGV[1]) end local cur = redis.call('get', KEYS[1]) if tonumber(cur) > 0 then redis.call('decr', KEYS[1]) return 1 end return 0出场时incr回来，然后定期（比如每天凌晨）用数据库统计数据做一次校准：
SELECT COUNT(*) FROM parking_order WHERE garage_id=? AND status=0之所以做校准，是因为实际运营中经常有入场车没出场、出口识别失败导致余位不增等情况，需要以真实的在场车辆数为准回写余位。注意这里要加一个分布式锁，避免多台设备同时校准导致数据错乱。
3.2 车牌识别与车辆入场逻辑
车牌识别是整个系统最依赖硬件质量的环节。识别摄像头选型非常关键，别只看像素，重要的是在夜间和雨天对车牌的反光材质处理、强光抑制和补光效果。实际测试中，同一款算法搭配不同硬件的识别率可以差出十几个百分点。
入场逻辑有一个容易漏的小细节：两辆车同时接近入口时，摄像头可能会把后车车牌识别成前车的一部分。解决方式是等车辆到达压力波传感器或地感线圈触发后再抓拍，而不是连续视频流识别。另外，识别结果要加一个置信度阈值，低于阈值就进入人工审核队列，免得错误识别导致后续计费错乱。
流程上，当device-gateway收到摄像头回调：
- 先校验车牌号格式，正则匹配，省份简称+字母+数字的组合。
- 判断是临时车、月租车还是黑名单车辆。
- 如果是月租且在有效期内，直接放行并推送入场服务通知。
- 如果是临时车，创建入场记录，余位减一，库存正常。
- 如果后缀命中黑名单（欠费、逃费），闸机保持关闭，并通知现场安保人员。
其中第3步是唯一允许“先开闸后记录”的场景，因为月租用户的体验在小程序里最关键，他会直接续费续月卡，多给他一秒等待都不行。
3.3 停车计费与订单管理
计费规则是整个系统里最容易出bug的模块。很多车场的计费规则复杂到超出想象力：首小时内10元，首小时后每半小时5元，不足半小时按半小时收；跨时段要分别计算；夜间有封顶价；节假日有浮动价；月租车和临时车规则又不一样。
我的建议是把计费规则做成一个配置化的策略模式，不要写死在代码里。规则表达式简化如下：
{ "periods": [ { "start": "08:00", "end": "20:00", "firstHourPrice": 10, "firstHourUnits": 1, "laterUnitPrice": 5, "laterUnitDuration": 30, "maxPrice": 60 }, { "start": "20:00", "end": "08:00", "firstHourPrice": 5, "firstHourUnits": 1, "laterUnitPrice": 2, "laterUnitDuration": 60, "maxPrice": 15 } ], "freeDuration": 0, "settlementSteps": 0 }当车主出场时，后端根据入场时间、当前时间，遍历时间段切分后计算应付金额，再把金额传到支付环节。注意跨时段计费必须按分钟粒度切分，然后对每个时段内的时长单独计算费用，否则很容易出现“停了一个跨夜的车，费用比实际应缴多了一倍”的投诉。
订单状态机也要画清楚。我设计了这样一个流转：
- CREATE：入场已创建，未支付
- WAIT_DEPART：用户打开了支付页但未付款，订单挂起不结算
- PAID：支付成功，等待出场核验
- FINISH：车辆已出场，订单关闭
- REFUND：支付后15分钟未出场，且调度自动发起退款
这个状态机要配合定时任务扫单，将所有“PAID后超过出场宽限时间还未离场”的订单做二次确认，进一步避免资金风险。
3.4 地图找位与场内导航
地图这块我纠结了很久，最初想引入室内地图SDK，但被成本和技术复杂度挡了下来。最后采用了简化三步走的方案，效果完全可以接受。
第一步，车场入口放一个二维码，车主扫码直接进入该车场的小程序页面，看到车位余量和收费规则。 第二步，小程序地图上展示车场位置和当前余量，基于腾讯地图或高德地图的Marker和周边检索，用户一键点击跳转到导航。这里不需要自己写地图服务，直接用各大地图的URL Scheme调起外部导航。 第三步，场内导航退而求其次，做成“分区指引”。每个区域在天花板挂了不同颜色的指示灯，小程序里提示“A区剩余23个B区已满，请前往A区”，这比像素级室内导航便宜得多，实用性却高得多。
有一说一，真正车位级的室内导航需要蓝牙信标阵列、手机端陀螺仪融合定位，开发量和成本不成比例地翻倍，大多数项目没必要。这属于是典型“知道核心目标是什么”的判断。
4. 微信小程序端的核心开发实录
4.1 页面结构与核心交互
小程序端我规划了五个主页面：
- 首页：定位当前附近车场列表，展示车场名称、距离、余位数、收费规则、开放状态。
- 车场详情：展示车场详情信息，地图导航入口，剩余车位动态数字，包月购买入口，历史订单列表。
- 停车记录：用户所有入场出场历史，每单展示入场时间、出场时间、金额、支付状态。
- 我的车辆：管理车牌绑定、默认车辆选择、开通/关闭免密支付。
- 个人中心：账号信息、发票抬头管理、客服反馈入口。
首页的一个设计注意点是不要做太花哨，用户打开小程序的路径极短，核心动作是“查询剩余车位”和“支付出场费”，这两个功能必须在首屏直接露出并一键可达。我们把“输入车牌缴费”做成首页的一个金刚区按钮，下面才是附近车场列表。不要问我为什么，这是AB测试测出来的数据，用户到停车场门口急着走，没人愿意在层层跳转里找缴费入口。
4.2 登录授权与车牌绑定
小程序的登录流程我在早期版本踩过坑。最初的方案是每次启动都用wx.login拿code换openid，这样获取了用户身份。后来发现微信调整了隐私政策，对手机号授权和用户资料的获取越来越严格，盲目弹窗申请授权会被用户反感，也会影响小程序的审核。
正确做法是采用“静默登录+关键节点引导授权”：
- 进入小程序后只wx.login换取openid，不弹窗授权任何隐私接口。
- 用户需要缴停车费时，再引导绑定车牌（这里不用手机号，只要车牌+车型，一个简单的表单校验就能完成需求）。
- 如果要推送出场提醒，由于需要订阅消息的权限，必须用户在支付成功页手动确认“允许发送服务通知”，这个时机用户需求最强烈，授权率最高。
温馨提示：如果你把首次启动就弹出手机号授权框，小程序审核被拒概率极高，因为系统会判定为“非必需场景强制收集用户敏感信息”。一定要做到最小化采集。
4.3 微信支付集成与免密代扣
支付是整个系统的资金命脉，也是最复杂的集成部分。小程序端主要实现三个能力：
支付场景一：临时车缴费。用户输入车牌号，后端查出当前入场记录并返回应收金额，小程序端调起微信支付，支付成功后跳转结果页。
支付场景二：包月购买。针对月租车，后端生成一个商品订单（连续包月或单月），走微信支付的JSAPI下单。这里的特殊点是周期履约，需要把微信支付订单号和内部月卡订单绑定，支付回调后激活月卡有效期。
支付场景三：免密代扣。这是把体验从“扫码付”升级到“无感停”的关键一步。用户在小程序绑定车牌时需要同时开通“车主服务”下的微信支付分代扣。此处需要申请微信支付分相关接口权限，而且开通时每次都要跟用户二次确认额度与周期。开通后出场时后端直接调用扣款接口，扣款成功即放行。
集成微信支付最需要注意的三件事：
- 回调验签：回调通知里有sign字段，必须用平台证书验签，绝不能轻信回调内容。有人伪造支付回调导致订单免单，这风险吃不起。
- 幂等处理：如果回调因网络问题被重复投递，后端必须保证同一个订单不会被重复入账。实现方式是在订单表上做唯一约束，回调处理前先查询订单状态，已处理过则直接返回成功标记。
- 对账定时：每天凌晨做一次微信支付账单与本系统订单的对账任务，以平台账单为准修正订单状态。这条是救命的，因为线上偶发丢单谁也无法完全避免。
4.4 车位状态实时展示的技术方案
如果车场比较大，首页车场列表要显示实时的余位数，这里有两个技术选型。
一是WebSocket长连接推送。适合车场详情页，用户进入后建立长连接，服务器端每秒（或每仓位变化）推送一次最新的余位数据。优点是实时性好，缺点是长连接在高并发下对后端有一定压力。
二是定时轮询。简单粗暴，用小程序端的setInterval每隔10秒请求一次余位接口。优点是服务端逻辑简单，缺点是流量浪费，且页面退到后台时定时器会失效，容易造成用户看到的数字不新鲜。
我最终采用的方案是混合策略：
- 车场列表页使用轮询，30秒一次，这个频率足够，且会依据页面可见性自动暂停。
- 车位详情页使用WebSocket，因为用户在这页停留时间最长，对实时性最敏感，且只有这一个用户实例，服务端压力不大。
同时加了一个“信任标签”——列表页余位数据过了60秒未刷新时置灰，细节上降低用户的预期管理，避免“明明显示有空位结果到了说没位置”的投诉。
5. 上线前遇到的典型问题与排查实录
5.1 支付回调不成功导致订单悬空
这个坑在联调阶段反复出现。现象是用户在支付界面付了钱，但小程序显示“支付确认中”，过一会儿点击“我已付款”没反应，后台订单状态还是未支付。
排查步骤：
- 先看微信支付商户平台对应的订单交易时间。这里能看到支付状态和回调通知记录。
- 后端日志有没有收到回调通知。如果完全没收到，大概率是回调URL配置错误，或者回调URL不能被外网访问（比如没开放云服务器安全组端口）。
- 如果回调收到了但业务处理报错，那一般是签名校验失败或订单状态已经被更早的请求修改了。
- 最终修复：老项目里回调处理函数里在操作数据库时碰到一个字段约束报错，异常未捕获导致事务回滚，外层框架直接把回调当成处理失败，微信端重复通知几次后则放弃。修完后加了全局异常兜底，所有回调都要能“安全失败”。
事后加了一个独立补偿任务：每隔一分钟扫描支付状态异常但支付时间已超过3分钟的订单，主动去微信查单接口核对，状态为已支付则修正本地订单。从那以后这种问题不再需要人工介入。
5.2 车牌识别不准：夜间与雨天场景
设计阶段对识别率的估计太乐观，实际场景中被反复吊打：
- 夜间车牌反光低，识别率直接砍掉20%。
- 雨天泥水遮挡车牌，部分字符完全无法辨认。
- 新能源车牌（绿牌）比蓝牌字符多一位，早期的正则写死6位直接误判。
这里的优化方向是软硬结合。硬件上要求摄像机加装智能补光灯，根据环境亮度自动调节；软件上增加多次抓拍融合算法，同一辆车连续抓3张图，通过投票或置信度加权得到最终结果。对于仍然不可信的识别结果，把图片缓存到后台，由运营人员人工复核，同时允许车主在小程序里自主修正车牌（修正前不结算离场）。
另外，入场识别错误会自动连带出场问题——入场记录里的车牌是错的，出场时识别正确的车牌却找不到入场记录，导致抬不了杆。设计初期没考虑这种关联场景，后来增加了一个“相似车牌匹配”的兜底策略：按入场记录的省级字和末位数字做模糊匹配，人工确认后创建正确入场记录并关联离场。
5.3 小程序审核被拒
我遇到过一次被拒是因为申请了“附近的小程序”类目，但实际页面没有完全按照微信的规范做。这个场景发生于第一次提交，被拒理由是你的小程序在未获得相关授权的情况下使用了用户地理位置接口。
处理方式是调整了定位逻辑：初始不调用任何地理位置授权，只有用户主动点击“附近车场”按钮时才调用wx.getLocation，在调用前弹出提示说明用途。同时在地图选择上，直接使用微信内置地图组件，减少原生插件的涉外风险。
另外提醒一句：支付类目需要在小程序后台提前完成“微信支付”商户号绑定，没有绑定商户号的类目审核基本都会被拒。
5.4 高并发场景下余位数据被重复扣减
最初把余位扣减写成了“先读后写”的普通逻辑，在并发测试中跑出多个线程读到同一个数然后都减一的bug——其实就是超卖。比如还剩最后一个车位，两辆车同时入场，一个显示成功另一个也显示成功，数据库层面的最终在场车辆数就会不对。
修复方案有两层：
第一层，Redis加分布式锁，但锁粒度不能太小。第二层是彻底改成Lua脚本原子操作，前面已经给了代码示例，这里就不再重复。最终效果是即使并发到达几百QPS，数字也毫厘不差。
定位出这个问题的过程也是典型案例。起初问题只出现在早高峰，直接表现为余位从5突然跳到2，排查时我先看了运行时日志，没发现业务异常，后来用压力测试脚本跑到并发100才稳定复现，于是锁定到并发控制缺失。万万不可小看停车场早晚高峰并发，一个核心商圈的车场，早高峰入场峰值能到每分钟50辆车，一旦多车场接入同一个后端，这并发就很可观了。
6. 实测效果、线下部署与优化建议
6.1 落地后的数据表现与复盘
整套系统实际上线跑了三个月后，我做了一次复盘，几个关键数字令人欣慰。
临停车辆入场平均耗时从原来的人工取卡式的35秒降到流程化的8秒（从触发线圈到抬杆放行），出场缴费从排队等扫码的50秒降到免密支付下的秒级放行。月租车次入口通行效率接近无感。从运营方角度看，车场日均停靠车次提升了约两成，因为车主看到“还有空位”的信心足了，也更愿意来了；而人工收费岗的夜间班次直接砍掉，每个月节省了两个人力的成本。
最值得分享的是免密支付的开通率只有三成，但使用免密支付的用户，月度活跃停车频次高于全量均值近一倍。这验证了一个判断：真正高频的用户才会做这种“授权”。产品运营要做的不是拉高开通率，而是服务好这批高价值用户。
6.2 部署上线后的运维风险及控制
停车系统属于业务型系统，上线后最怕的其实是“业务事故”，比如用户付了钱出不了场。为此我做了三层控制：
- 设备侧：道闸控制器在网络异常时进入本地模式，只开闸不记录，待网络恢复后批量上传入场记录，避免导致场内车辆大量积压。
- 系统侧：订单支付状态以微信支付商户平台的“最终一致性”为准，本地缓存的支付状态只用于展示。
- 客服侧：现场保全电话直连运维值班人员，值班人员有后台人工放行权限。自动化的“确认支付后自动抬杆”当然好，但整个系统必须保留一个人工兜底出口，这是现实世界的铁律。
6.3 后续迭代的几个方向
完成基础闭环后，再往上的优化空间就清晰了。我目前排了几个优先级较高的方向：
- 会员体系：充电、洗车、保养优惠打包进会员权益，提升车主粘性。
- 预约车位：针对社区和写字楼的固定车位分时出租，盘活白天闲置的小区车位。
- 数据看板：以车场为单位分析高峰时段、平均停车时长、周转率、应收高峰，给运营提供调价参考。
- 跨车场互认：一个账号通停多个场，类似与第三方平台的车场权益联盟，这个对商务拓展的价值大于技术开发。
从我个人的实操体会来说，这套系统的难度不主要在技术实现上，真正难的是对业务细节的理解和敬畏。计费规则、异常流程兜底、设备断网处理，这些比“写一个地图找位”难得多，也重要得多。尤其当你面对的是真实车场每天几千车次的高频运转时，任何一点数据不一致都会被放大成客户投诉。
最后分享一个小技巧：做这类系统时一定要先写出一份《现场异常处理手册》给车场保安。因为不管系统多么完善，总会遇到极端情况（比如前车刚过闸突然倒车、车牌遮挡严重、系统误判重复抬杆）。手册里写清楚“先保通，再追究”的原则，任何时候不要让车主堵在出入口，保障现场通行流畅永远是第一位的。这样一套基于微信小程序的智慧停车系统，技术含量和市场价值都是在一次次实际运营中沉淀出来的。
