1. 车辆出入管理这个场景，为什么值得用小程序重做一遍

先说一个我观察很久的现象：很多园区、厂区、住宅小区的车辆出入管理，硬件其实早就换过一轮了——道闸是新的，摄像头是高清的，识别率也不差，但真正让人难受的地方从来不在硬件上。保安室里那台老电脑跑着一个界面停留在十年前的客户端，临时访客来了要手写登记本，月租车到期了要打电话通知，业主想查自己车昨天几点进的、停了多久，答案是"你等一下，我问问岗亭"。硬件在2020年代，流程还停在2010年代，这就是绝大多数中小型场景的真实现状。

基于微信小程序的车辆出入管理系统要解决的正是这一层的问题。它不负责车牌识别本身——那部分交给摄像头和识别算法一体机；它负责的是识别结果之上的那一整套业务流转：车辆档案怎么建、访客车怎么临时放行、月卡怎么续费、进出记录怎么被车主自己查到、异常抬杆怎么留痕、多岗亭之间数据怎么同步。换句话说，它是把"识别出一个车牌号"这件事，变成"一次可追溯、可管理、可自助服务的通行事件"。

这个题目适合谁看？我把它分成三类读者。第一类是接到类似需求、准备动手做的开发同学，你需要一套能落地的技术选型和数据模型，而不是一份教科书式的需求文档；第二类是场地方的运维或管理人员，你想知道这套东西到底能管到什么颗粒度、哪些环节能省人力、哪些环节反而会增加麻烦；第三类是已经在做智慧园区类项目、想补齐小程序端这一块的从业者，你更关心的是权限模型、消息触达、离线容错这些容易翻车的地方。三种人关注点不同，但共同点是：都不想听空话，只想知道具体怎么做、为什么这样做、哪里会踩坑。

我这里要提前说清一个立场：小程序在这个系统里的定位是"轻客户端 + 业务中台的门面"，不是全功能替代品。有人一上来就想把道闸控制、实时视频流、人脸比对全塞进小程序，这个方向我不建议。小程序的优势在于"用户已经装了微信、打开成本几乎为零、消息能主动推到人"，劣势在于长连接能力弱、后台运行受限、硬件直连能力差。所以正确的切法是：实时性要求高的、和设备强耦合的（比如抬杆指令下发、视频抓拍回传）走服务端和岗亭客户端；面向车主和访客的查询、预约、缴费、通知，全部走小程序。这条边界如果一开始划错了，后面会返工得很痛苦。

还有一个常被忽略的点：这个系统的真正复杂度不在技术栈，而在业务状态的组合爆炸。一辆车可能是月租车、可能是储值车、可能是访客预约车、可能是黑名单车、可能是多辆车共用一个车位、可能在免费时段内、可能跨零点计费、可能入场时是访客车出场时变成了月租车（中途办了月卡）。这些状态两两组合，就是几十种分支。很多系统上线后天天出问题，不是代码写得烂，是当初建模的时候只考虑了"正常车正常进出"这一条主路径。所以下面的内容我会花相当大的篇幅讲数据模型和状态机，这部分的投入产出比远高于你去抠界面细节。

2. 技术选型：为什么是小程序 + 独立后端，而不是别的组合

2.1 三种常见架构的取舍对比

在动手之前，架构选型这一步几乎决定了后面所有工作的形态。我见过三种典型做法，各有各的道理，但适配的场景差别很大。

我倾向第三种，但要说清楚它多出来的成本在哪。多出来的成本主要是设备网关这一层：不同厂商的道闸和识别一体机，通信方式差别很大，有的是 TCP 长连接私有协议，有的是 HTTP 回调推送，有的是 MQTT，还有相当一部分只提供 SDK 或串口透传。你需要写一层适配，把"设备语言"翻译成统一的内部事件。这层的存在感很低，但它是整个系统稳定性的地基，一旦做薄了，后面所有业务逻辑都建在沙子上。

2.2 后端技术栈的具体考虑

后端我一般选Java（Spring Boot）或 Node.js（NestJS），两者在这个场景下都够用，区别在于团队熟悉度和设备网关的实现方式。如果设备侧大量是 TCP 私有协议、需要维持长连接和心跳，Node.js 的事件循环模型写起来更顺手，一个进程挂几百个设备连接没什么压力；如果业务侧复杂（计费规则、报表、权限），Java 的生态和类型约束会让长期维护更省心。

数据库这块，我的建议是MySQL 存业务数据 + Redis 存实时状态和幂等控制，不要一上来就上分布式那一套。这个场景的数据量级其实很小：一个千车位规模的园区，一天出入记录也就几千条，五年数据量撑死几百万行，单机 MySQL 加好索引完全够。真正需要 Redis 的地方是两个：一是实时在场车辆表（谁现在在里面），这个要高频读写，放内存里做；二是幂等键，防止设备重推、网络重试导致同一条进出记录被写入两次，这个问题后面会专门讲。

小程序端的选择相对简单：原生小程序开发 或 uni-app。如果只有微信一端，原生开发调试体验最好，云开发能力也能顺手用；如果后面可能扩到其他平台，uni-app 更保险。但有一点必须提醒：不要用小程序云开发承载核心业务数据。云开发在做原型时很爽，但一旦涉及多角色权限、复杂事务、设备回调，很快会撞墙。业务数据一定要放在自己的后端，小程序只做展示层和交互层。

2.3 小程序在这个系统里的能力边界

把边界说透，能省掉大量无效沟通。小程序的强项：微信授权登录拿 openid，天然绑定用户身份；订阅消息可以主动推送（月卡到期提醒、访客到访通知、缴费成功）；扫码能力可以用来做访客二维码通行；支付能力可以接续费。小程序的弱项：不能常驻后台、无法直连局域网设备、蓝牙/NFC 能力受限、请求有并发和超时限制。

所以在设计时，凡是"需要实时看到设备状态"的功能，我都放到服务端去做轮询或者事件推送，小程序端只展示"最近一次同步时间 + 当前状态"，并给一个手动刷新按钮。这个设计看起来笨，但极其可靠，比你在小程序里搞长连接轮询要稳得多。

3. 数据模型与状态机：这个系统的地基

3.1 五张核心表的职责划分

我做一个项目，习惯先把表结构画清楚，因为表结构错了，代码怎么写都是错的。这套系统里真正核心的表不多，五张基本能覆盖：

• vehicle（车辆档案）：车牌号（唯一键，注意统一大写去空格）、车主ID、车辆类型、颜色、品牌、绑定状态、创建时间。这里有个细节——车牌号要单独存一份"标准化车牌"字段用于唯一索引，因为用户输入时可能带空格、全角字符、省份简称写法不一致。
• owner（车主/用户）：openid、手机号、姓名、审核状态、所属组织（如果是企业园区）。openid 是微信侧的唯一标识，但它只在单个小程序内唯一，所以要有内部主键。
• pass_record（通行记录）：车牌、入场时间、出场时间、入口设备ID、出口设备ID、入场图片URL、出场图片URL、通行类型、计费金额、放行方式（自动/人工）。这张表是数据量最大的，索引要建在（车牌, 入场时间）和（入场时间）上。
• parking_space（车位/区域）：区域名、总车位数、已占用数、区域类型（月租/临停/访客）。如果场地小可以简化为一个配置项，但只要有分区就必须建表。
• visitor_appointment（访客预约）：访客车牌、被访人、被访人所属组织、预约时间段、通行码、状态、实际入场时间。这张表是访客流程的核心。

除了这五张，还会有rule（计费规则）、device（设备台账）、gate_log（抬杆指令日志）、audit_log（人工操作审计）。我给的建议是：审计日志一定要有，而且从第一版就要有。人工抬杆是最容易出纠纷的动作，谁在什么时间因为什么原因给哪辆车放了行，必须有据可查。后期补这个功能，历史数据就永远缺失了。

3.2 车辆类型的组合判断逻辑

前面说过状态组合是这个系统的难点，具体体现在通信类型判断上。一辆车到达道闸，系统的判断顺序大致是这样：

1. 查车牌是否在黑名单里 —— 命中直接拒绝，不进入后续流程。
2. 查是否有当前有效的访客预约—— 命中且在时间段内，放行并记为访客通行。
3. 查是否是月租车/授权车—— 命中且授权期有效，放行。
4. 查是否是储值车—— 命中且余额够，放行并扣费。
5. 以上都不命中，按临时车处理，入场放行、出场计费。

这个顺序不能乱。我见过把访客判断放到月租之后的系统，结果访客的车牌如果恰好和某个已过期月租车重复，就会被判成"月租过期拒绝入场"，访客在门口打不通被访人电话，体验极差。优先级的本质是"哪个判断更具体、更有时效性，哪个先判"。

还有一个隐蔽的坑：授权期边界。月租车在到期当天算不算有效？严格按自然日的话，到期日 23:59:59 之前有效，之后失效。但如果车上人在 23:58 入场、次日 00:30 出场，出场时已经过期了怎么办？我的做法是入场时锁定授权状态并写入通行记录，出场时以入场时的快照为准，同时给出场后的续费留一个补缴入口。这个设计避免了"进场时好好的，出场时被卡在闸机口"的尴尬，代价是要多一个字段。

3.3 一次通行事件的完整状态流转

把状态机写出来，比讲十遍需求都管用。一次通行的状态大致是：待识别 → 已识别 → 权限校验中 → 校验通过/校验拒绝 → 指令已下发 → 设备已确认 → 记录已归档。其中"指令已下发"和"设备已确认"必须分开，这是个关键设计。

原因很实在：服务端告诉道闸"开闸"，道闸回一个 ACK，但这不代表杆子真抬起来了——可能机械卡住、可能地感线圈没检测到车、可能杆子抬到一半遇阻回落。如果你的系统把"指令下发成功"就当成"通行成功"，那记录里全是漂亮的数据，现场全是投诉。正确做法是：指令下发记一次日志，设备回报抬杆到位再记一次，两次都成功才算通行完成；超时未回报则进入异常队列，由岗亭端弹窗提示人工介入。

这个异常队列我强烈建议做成必须处理的阻塞项，而不是一个可以忽略的统计数字。实际运行中，每天总会有几辆车因为跟车太紧、车牌污损、地感失灵被卡住，如果系统只是冷冰冰记一笔"异常"，保安还是得靠肉眼发现，那这套系统的价值就少了一半。

4. 车主端小程序：把查询和自助做扎实

4.1 登录与车辆绑定的安全设计

小程序端第一步是身份，第二步是车辆归属。微信登录拿 openid 很简单，但"这个 openid 对应的人，凭什么能绑这辆车"是需要设计的。我的方案是双因子绑定：用户提交车牌 + 手机号，系统校验该手机号是否已在物业登记（或者发送短信验证码验证手机号真实性），两者匹配才允许绑定。整个过程要留审核状态：待审核、已通过、已驳回，驳回要带原因。

为什么不能只靠车牌自助绑定？因为车牌是公开信息，谁都能看到别人的车牌。如果只填车牌就能绑，任何人都能查到别人车辆的进出记录和停放位置，这是严重的隐私问题。车辆轨迹属于个人敏感信息，绑定关系必须有归属证明。这一点在项目初期就要和需求方讲清楚，避免后期被要求"简化流程"而被迫留个洞。

另外一个小细节：一个用户可以绑多辆车，一辆车只能绑定一个主用户，但可以有多个"关注者"（比如家庭成员）。关注者只能看记录不能改信息、不能缴费，这个区分在住宅场景里很实用，也避免了夫妻两人抢着绑同一辆车导致互相顶掉。

4.2 进出记录查询的体验细节

查询功能看起来最简单，其实最容易做得难用。用户的真实诉求往往不是"我要看全部记录"，而是三个具体问题：我的车现在在不在里面？我今天停了多久、花了多少钱？我这个月一共停了多少次？

所以首页不要放一个空的记录列表，而是放三块状态卡：当前在场状态（在场/不在场、入场时间、已停时长实时计时）、本月统计（次数、累计时长、累计费用）、待办提醒（月卡即将到期、有未缴费用）。列表放第二屏，按时间倒序，支持按车牌筛选（多车用户刚需）。

技术上要注意两点。第一，在场时长要用服务端时间计算后下发，不要用客户端本地时间算，否则用户改手机时间就能"少停一会儿"。第二，图片 URL 要带签名和过期时间，不能直接把存储桶的裸地址给前端，否则记录里的车辆照片可以被任意转发和长期访问，同样是隐私问题。

提示：出入场照片建议只保留 30 到 90 天，配合存储的生命周期规则自动清理。既降低存储成本，也降低数据泄露的风险面。这个保留期要在用户协议里写明。

4.3 月卡续费与到期的触达链路

续费是这个系统里少有的"能直接产生收入"的功能，做好了对场地方是真金白银。链路设计上，我建议做成三层触达：

第一层是提前 7 天的订阅消息，提醒"你的月卡将于 X 月 X 日到期，点击续费"。第二层是到期前 1 天的再次提醒。第三层是到期后入场时的拦截提示——车在入口被识别为过期，系统不是简单拒绝，而是给车主推一条消息"你的月卡已过期，可点击此处在线续费，续费后请重新识别入场"。这三层的转化率差别很大，第三层的转化最高，因为用户当下就有强需求。

订阅消息有个坑必须提前踩明白：微信订阅消息需要用户主动授权，且一次授权只能推一条（一次性订阅）。想要长期推送就得用长期订阅，但长期订阅对类目有要求，不是所有小程序都能申请下来。所以务实的做法是：在用户每次进入小程序、每次缴费成功时，都请求一次订阅授权，攒推送次数。这个交互设计要做得自然，别一进来就弹窗要授权，用户会直接关掉。

支付这块，涉及金额的接口必须做服务端校验 + 幂等处理。用户点两次、网络重试、回调重复到达，都可能造成重复扣费或重复延期。我的做法是：每次下单生成唯一的业务订单号，回调按订单号做幂等，处理前先查订单状态，已处理直接返回成功。这套逻辑写起来不复杂，但省掉的是大量的客服工单。

4.4 访客邀请：把纸质登记本彻底干掉

访客流程是我认为这套系统里用户感知最强的部分。传统流程：访客到门口，保安问找谁，打电话确认，手写登记，抬杆。新流程：被访人在小程序里填访客车牌和来访时间，生成一个带时效的通行凭证（可以是二维码，也可以是直接授权车牌），访客到门口车牌自动识别放行，同时被访人收到"你的访客已入场"的通知。

这里有个设计选择：用二维码还是用车牌授权？我的建议是车牌授权为主、二维码为辅。车牌授权体验最好，访客什么都不用做；但如果访客临时换了车、或者车牌识别失败，二维码就是兜底。二维码要带签名、带有效期、一次性使用，扫码后立即失效，防止截图转发被滥用。

被访人身份也要校验——不能随便谁都能发起访客邀请。住宅场景下要校验该用户是否是本小区已审核业主；企业园区场景下要校验所属企业和在职状态。访客邀请本质上是"把一个临时的通行权限授予一个陌生人"，授权人的身份可信度决定了整个流程的安全性。

访客还有一个容易漏的点：超时未离场。访客预约的是 2 小时，结果车停了一整天。系统要能识别"访客已入场但超过预约结束时间仍未出场"，并推送给被访人提醒，同时在出场时按临时车规则补收费用。这个规则要在预约时就告知，别等出场才说，容易起争执。

5. 管理端与岗亭端：把日常运维的活儿接住

5.1 岗亭端的核心界面只有三个

很多系统在岗亭端做了一堆界面，结果保安一个都不用。原因很简单：岗亭里的操作必须在一两秒内完成，任何需要点三下才出来的功能都是失败的。我总结下来，岗亭端真正高频的只有三块：

第一块是实时通行流水，滚动的列表，每进出一辆车就冒一条，带车牌、类型、放行方式、抓拍缩略图。保安扫一眼就知道刚才发生了什么。第二块是异常处理弹窗，识别失败、权限拒绝、抬杆超时，都要立刻弹出来并带一个醒目的"人工放行"按钮，点了之后必须填原因（下拉选：访客未预约/月卡刚过期/车牌污损/设备故障）。第三块是在场车辆查询，输入车牌能立刻看到这辆车现在在不在里面、从哪个口进的、停了多久。

这三块做好了，80% 的日常场景就覆盖了。剩下的报表、配置、档案管理，全部放到 Web 管理端，让管理员在办公室用电脑做，不要挤在岗亭那块小屏幕上。

5.2 人工抬杆的审计闭环

前面提过审计日志，这里展开说。人工抬杆是整套系统里唯一的"人为绕过规则"的动作，也是最容易产生纠纷和舞弊的地方。我的设计是四要素强制记录：操作人、时间、车牌、原因，缺一不可，而且原因必须从预设选项里选，不允许自由输入（自由输入等于没有统计价值）。

更进一步，我建议加两个约束。其一，同一操作人在短时间内对同一车牌多次人工放行，触发告警并推送给主管。这个规则拦住的不是好人，而是那种"熟人车天天抬"的灰色操作。其二，人工放行的记录要在日终报表里单独成列，让管理者每天都能看到这个数字。数字一旦被看见，行为就会收敛，这是管理上的常识。

注意：审计日志只能追加不能修改，也不建议提供删除功能，哪怕是管理员。真要清理只能按时间归档到冷存储。这条约束在项目初期就要写进设计，后期再想加，历史数据已经脏了。

5.3 报表要解决的是"老板想知道什么"

报表做了一大堆图表，没人看，是因为没对上问题。管理者真正关心的通常是这几个：今天进出了多少车次、当前在场多少辆、还有多少空位、临时车收入多少、月租车续费率和到期未续名单、人工放行次数、异常通行次数、各时段车流高峰。

其中到期未续名单是最有商业价值的。这个名单直接对应着可以打电话挽留的客户，比任何花哨的可视化都有用。各时段车流高峰则能指导排班——如果早上 8 点到 9 点入场量是全天峰值，那这个时段岗亭必须双人。报表的价值不在好看，在于能直接支撑一个决策动作。

技术上，报表查询一定要和业务库做读写分离或者单独的统计表。直接对 pass_record 做大范围聚合查询，在数据量上来之后会拖慢主库，进而影响通行写入，这是最不能接受的事故——报表慢没人骂，道闸卡了全场骂。

5.4 多出入口与多岗亭的数据一致性

单出入口的系统好做，多出入口就开始出问题。典型场景：车辆从 A 口入场，从 B 口出场，两个口分别由不同的岗亭客户端和不同的服务节点处理。如果入场记录还没落库，出场就已经在处理了，系统会认为这辆车"没有入场记录"，按临时车或者异常处理。

解决思路有两个层面。业务层面，出场时如果查不到入场记录，不要立即拒绝，而是查"最近 N 分钟内该车牌的识别事件缓存"，如果缓存里有入场事件但尚未落库，就以缓存为准并异步补全。技术层面，入场和出场的写入必须走同一个数据源，不能一个写主库一个写从库，主从延迟在这个场景下是致命的。我一般会要求：通行记录的写入和查询强制走主库，报表和列表查询才走从库。这个规则要写进代码规范，不然新同事一个 from slave 就可能埋一颗雷。

6. 最容易翻车的几个环节与我的处理方式

6.1 设备重复推送与幂等设计

这是我在实际项目里被教育得最狠的一次。识别一体机在网络抖动时会重发事件，服务端网络超时重试也会重发请求，结果同一辆车的一次入场被写成了三条记录，出场时匹配到三条，计算出的停车时长和费用全是错的，用户直接投诉到物业。

修复方案是三层幂等。第一层在网关：设备事件带唯一事件 ID（厂家一般会给，或者用 设备ID + 车牌 + 时间戳到秒 拼一个），Redis 里 SETNX 一个 5 分钟过期的键，重复的直接丢弃。第二层在服务：写通行记录前，先按（车牌, 入场时间窗口 ±3 分钟, 未出场）查一次，存在则更新不新增。第三层在数据库：给通行记录加一个业务唯一索引，比如（车牌, 入场时间, 入口设备ID），让数据库做最后一道兜底。

三层里，第一层是性能最优的，第三层是最可靠的，中间那层负责覆盖"事件 ID 不同但业务上确实是同一件事"的情况。三层都做，成本其实不高，但能挡掉九成以上的脏数据。

6.2 车牌识别的误识别怎么处置

识别率再高的设备也有认错的时候，"京A12345"识别成"京A1234S"，或者相邻两辆车跟得太紧，把前车的记录算到后车头上。这类问题不能靠提高识别率解决，只能靠流程兜底。

我的做法是分场景处理。入场误识别影响小，因为出场时还会再识别一次，如果两次车牌对不上，就在出场时进入人工确认流程，弹出两张抓拍图让保安比对。出场误识别影响大，因为直接决定收费，所以出场环节要加一道"相似车牌提示"——系统把识别结果和在场车辆库做模糊匹配（编辑距离 ≤ 2 视为相似），如果匹配到一辆在场的相似车，提示保安"是否是这个车牌"。

还有一个低成本的土办法很有效：入场时把抓拍图压缩后存下来，在出场异常界面上并排显示入场图和出场图。人眼比对两张图，三秒钟就能判断是不是同一辆车，比任何算法都可靠。这个功能实现起来就是两个 img 标签，但它在实际运维里的使用频率高得惊人。

6.3 断网、断电、设备离线时的降级方案

这套系统最不能接受的失效模式是"网断了，车全堵在门口"。所以降级方案必须在设计阶段就定好，而不是出事了再想。

我的分层策略是这样：服务端整体不可用时，岗亭客户端启动本地白名单校验模式，把最近的月租车和授权车信息缓存在本地 SQLite 里，能自动放行就自动放行，访客和临时车一律人工登记抬杆，事后补录。单个设备离线时，服务端标记该设备状态，并在管理端醒目提示，同时该口的通行改为人工模式。数据库不可用时，这是最严重的，此时应该直接进入全人工模式并报警，不要指望系统还能做判断。

这里的关键是本地缓存要定时全量刷新。我一般设成每小时同步一次白名单，同时在每次成功连接服务端时做一次增量同步。缓存不能太大，千车位规模的月租车名单也就几千条，压缩后几百 KB，完全放得下。

6.4 数据隐私与合规的几条硬线

车辆轨迹、车牌、抓拍照片、手机号，这些都属于需要认真对待的个人信息。我从项目里总结了几条自己一定会守的线。

第一，抓拍照片的访问必须走鉴权，前端拿到的是短时效签名 URL，不能是裸链接，且不允许被搜索引擎索引。第二，照片保留期限要明确，超过期限自动删除，我一般设 30 到 90 天，具体看场景需求。第三，手机号要做脱敏展示，列表里显示 138****5678，只有必要角色能看到完整号码，且查看动作要留痕。第四，导出的报表要去除不必要的敏感字段，很多人做导出功能图省事直接 select *，这是隐患。

还有一条容易被忽视：小程序收集用户信息要在隐私协议中说明用途，包括收集了哪些字段、用于什么目的、保存多久。这不是走形式，用户投诉时这是最基本的依据。

7. 上线之后才是真正的开始

7.1 灰度上线与并行运行的节奏

我不建议一次性把所有出入口切到新系统。稳妥的节奏是：先选一个车流量最小的出入口，新老系统并行运行两周，所有通行两边都记，每天比对两边的记录条数和金额。比对过程中一定会发现差异，差异就是 bug 清单，比测试用例找出来的还准。

并行期的关键指标有三个：识别成功率、自动放行率、异常率。识别成功率反映硬件和算法，自动放行率反映业务规则配置得对不对，异常率反映整个链路的健壮性。这三个数在并行期要每天看，降到可接受范围再扩大范围。

7.2 上线后最常见的三类问题

第一类是规则配置错。比如免费时长配成了 0 分钟、月租车类型没加进白名单、某个口的方向配反了（入口当出口）。这类问题在新系统上线首周占比极高，特点是影响面大但修复极快。对策是上线前做一次规则核对清单，逐条过一遍，别嫌麻烦。

第二类是用户不会用。尤其是访客流程，被访人不知道怎么发起邀请，访客不知道要提前登记。对策是做一页图文并茂的操作指引，贴在岗亭、发到业主群，同时在小程序里做首次使用的引导浮层。这类问题靠技术解决不了，只能靠运营。

第三类是设备侧的小毛病。地感线圈灵敏度、道闸起落速度、摄像头补光角度，这些和软件无关但会表现为"系统不好用"。对策是上线后第一周安排人到现场蹲点，别远程指挥。现场的很多问题看一眼就明白了，远程排查能耗掉一整天。

7.3 我在这类项目里踩过的三个具体坑

第一个坑是时间戳的时区。设备上报的时间戳格式五花八门，有的是本地时间字符串，有的是毫秒时间戳，有的甚至不带时区。我遇到过设备用的是 UTC 而服务端按东八区解析，导致所有记录的入场时间都差了 8 小时，报表一看全是凌晨进场的车。教训是：所有入站时间在网关层统一转换成本地时间的标准格式，并且打上来源标记，业务层只认一种格式。

第二个坑是车位数的实时计算。总车位数减去在场车辆数等于空位数，听起来很简单，但只要有人工放行的车没登记、或者有车入场后一直没出场（识别漏了），这个数就会慢慢漂移，最后显示"剩 200 个空位"而实际早就满了。对策是定时对账：每天凌晨拿当天的入场数、出场数、人工放行数做一次平账，对不上的就生成一条待核清单。这个对账任务看起来土，但它能保证系统长期不跑偏。

第三个坑是小程序端的缓存。用户查了在场记录，车已经出场了，页面还显示在场。原因是前端做了页面级缓存，切回页面不重新请求。对策是在场状态这类强时效数据，页面 onShow 时必须重新请求，并且服务端返回数据带一个时间戳，前端超过 60 秒就显示"数据可能已过期，点击刷新"。

7.4 后续能往哪里长

这套系统跑稳之后，往上的空间其实不少，但我不建议一次做全。可以按这个顺序考虑：先是车位引导，在入口屏和小程序上显示各区域空位数，这个只需要把车位占用数据和区域关联起来；然后是反向寻车，用户在小程序里输入车牌就能看到车停在哪个区域、从入口怎么走过去，这个在大型园区里非常实用；再往后可以接充电桩管理，把充电车位的占用和计费纳入进来。

但我个人最看重的扩展方向是数据侧的沉淀。这套系统攒下来的通行数据，能做的事情远不止收停车费：比如通过长期的车流曲线判断哪些时段需要加派人力、通过访客来源分析判断园区的招商效果、通过车位周转率判断停车资源是否紧张。这些分析不需要多复杂的技术，一张按小时的聚合表加一个看板就能出结论，但它对管理决策的支撑，比再加十个功能页面都实在。