这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
路内和路外是两套业务模型：路外靠道闸卡住车，不缴费出不去；路内没有物理阻拦，车开走了只能事后追缴。同一个「订单」概念在两边含义不同。
四类设备来自不同厂商，接口形态完全不一样：路侧相机走厂商 SDK 或私有 HTTP 回调，道闸有 SDK 也有干接点，地锁走 LoRa 或 433M 私有协议，巡检车是移动端 4G 上传。没有统一标准可依。
地锁状态和订单状态存在最终一致性窗口：升锁指令下发后设备没响应，订单该不该结束？降锁失败导致车辆无法驶离，现场怎么兜底？这类边界状态比主流程难写得多。
道闸和地锁都必须在断网时能本地放行或本地开锁，否则一次网络抖动就会堵住出口。
项目背景：一个城投公司手里的两门生意
委托方是某地市城投公司，手里管着 4 个停车场，加起来约 3 万个车位。这些车位分两类：一类是有道闸、有围墙的路外场库，车进场取卡或识别车牌，出场缴费抬杆；另一类是划在路边的路侧泊位，没有杆，靠高位视频相机或地磁识别车辆停放。
两类车位的运营逻辑几乎是相反的。路外场库是「先拦住再收费」——车出不去，跑不掉；路侧泊位是「先服务后追缴」——车停完直接开走，只能靠记录和后续追缴。一个系统要同时管这两件事，最先撞上的不是功能设计，是概念对齐：什么叫一个「订单」、什么时候算「结束」、欠费怎么定义。
更麻烦的是设备层。4 个场地的设备是分批采购的，路侧相机、道闸、地锁、巡检车四类设备各有各的厂商和接口。项目启动时没有一份完整的设备清单和协议文档，是边接边摸出来的。
四类设备，四种接法
行业里常说「支持主流停车设备」，但真正落地时，「主流」这两个字没有意义——同一个厂商不同批次的固件，回调字段都可能不一样。我们把四类设备的接入方式拆开看：
| 设备类型 | 接入方式 | 主要数据 | 踩过的坑 |
|---|---|---|---|
| 高位视频路侧相机 | 厂商 SDK / 私有 HTTP 回调 | 车牌号、泊位号、进出时间、抓拍图 | 不同型号回调字段名不统一；同一辆车被相邻两个相机同时识别会产生重复订单 |
| 道闸 | 厂商 SDK + 干接点兜底 | 开关闸状态、地感触发、放行记录 | 部分老设备只支持干接点，无法回读状态，只能靠地感间接判断 |
| 智能地锁 | LoRa / 433M 私有协议 + 网关 | 升降状态、电量、故障码 | 指令下发是单向的，状态要靠设备主动上报，中间有几秒到几十秒的窗口 |
| 巡检车 | 车载终端 4G 上传 | GPS 轨迹、沿途车牌识别、抓拍时间 | 车在移动，同一车牌会被连续多帧识别，需要按轨迹去重而不是按时间去重 |
接入层我们做了一个统一适配层：每类设备写一个驱动，把原始数据归一化成统一的车位事件（泊位被占用 / 释放、车牌入场 / 离场）。上层业务只认事件，不认设备。这样后面新增设备型号时，只需要加驱动，不动业务代码。
高位视频相机的识别是「看得到就算」。相邻两个相机覆盖范围有重叠时，同一辆车会同时被两台设备识别，产生两条入场记录。如果按时间去重（比如 5 秒内同一车牌只算一次），车在重叠区停留超过 5 秒就会漏；正确做法是按泊位归属去重——先判断这辆车实际停在哪个泊位，只认那个泊位的主责相机。
计费：路内和路外不能共用一套规则
最初的设想是做一套统一的计费引擎，用配置区分场景。实际做下来发现这个方向不对——两边的计费维度根本不同。
- 路外场库：按「进场时间 → 出场时间」算时长，有免费时长、封顶价、包月套餐，出场时一次性结算。核心是「出场即结清」。
- 路侧泊位：按「泊位被占用时段」算，同一辆车在一天内可能停多个泊位、多次进出，每次是独立订单。核心是「先记账，后追缴」。
- 路侧还有一类特殊情况：车辆中途挪位。视频识别到泊位释放又占用，如果按泊位算会产生两个订单，按车辆算应该合并成一个。这里必须按车辆维度做时间轴合并。
最后做成了两个计费模型，共用一套费率配置和优惠规则，但订单生成逻辑分开。代价是多写了一份代码，好处是两边都不会因为对方的特殊需求被改坏。
欠费追缴是路侧独有的问题。车开走了没有物理阻拦，只能靠三件事：一是记录完整（车牌、时间、泊位、抓拍图齐全，才具备追缴依据）；二是提供多渠道补缴入口；三是和后续停车场景联动——同一辆车下次进入路外场库时提示欠费。第三点是最有效的，但涉及跨场景数据打通，需要运营方认可。
地锁的状态一致性，是这类项目最脏的活
智能地锁看起来简单：有车要停就降，车走了就升。但它是一个「指令单向、状态异步」的设备——你下发降锁指令，设备可能因为电量低、机械卡阻、信号弱而没执行，而你不知道，除非它主动上报。
这就带来一系列必须显式处理的边界状态：
| 场景 | 如果不处理会怎样 | 我们的做法 |
|---|---|---|
| 降锁指令下发后设备无响应 | 订单已生成，但车进不去，用户投诉 | 指令带超时，超时后自动重试一次，仍失败则推送到远程坐席并给用户发送替代泊位 |
| 升锁失败（车已走但锁没升） | 泊位显示空闲，实际被占用，下一个用户到了停不进 | 以相机识别结果为准修正泊位状态，地锁状态降级为参考值 |
| 降锁成功但车辆未驶入 | 泊位被锁定但无人使用，白占资源 | 设定锁定超时，超时自动升锁并释放泊位 |
| 设备离线期间有车停放 | 订单缺失，事后无法计费 | 以相机记录补单，地锁状态标记为「离线推断」 |
核心原则只有一条：**泊位状态的权威来源是相机，不是地锁**。地锁是执行器，不是传感器。想清楚这一点，大部分状态冲突就有了裁决依据。
巡检车：移动端采集的时序问题
巡检车的作用是补路侧相机的盲区——相机装不了或者被树挡住的路段，靠车巡回来识别。技术上是车载相机边开边识别车牌，同时记录 GPS。
难点在去重。一辆车停在路边，巡检车经过时可能连续识别到十几帧，间隔只有零点几秒。按时间去重（比如 10 秒内同车牌只算一次）在慢速巡游时可行，但车速快时同一个车牌可能只被识别到一帧，下一次巡逻才再出现，这时按时间窗口就会漏判。
我们改成按空间去重：把泊位坐标和巡检车轨迹做匹配，同一泊位在同一轮巡逻中只取置信度最高的一帧。这样无论车速快慢，结果都稳定。
地磁方案在路侧很常见，成本低、安装快。但它只能判断「有没有车」，判断不了「是谁的车」。要产生可追缴的订单，必须有车牌。所以这个项目在需要计费的路段用视频，在不计费只做占用监测的路段才考虑地磁。
断网必须能走：本地放行不是可选项
停车场最怕的不是系统功能少，是出口堵住。一次网络抖动导致道闸抬不起来，五分钟就能堵出几百米。所以从架构上就必须假设「云侧随时可能不可用」。
- 道闸控制器保留本地白名单和本地计费规则，断网时按本地规则计费并放行，恢复后补传流水。
- 地锁网关保留本地降锁权限，云端不可达时允许现场通过蓝牙或管理卡开锁。
- 所有设备侧操作都在本地留一份流水，网络恢复后按时间戳补传，云端做去重。
- 补传数据不重新触发计费，只做对账。否则会出现同一笔停车被算两次的问题。
这套「边缘可独立运行」的设计在方案阶段容易被砍掉——看起来是冗余。但真跑起来之后，它是最不该省的部分。
一个停车场的真实运营数据
系统好不好用，最终看后台的数字。这是其中一个停车场的运营后台累计数据（截至统计日）：
| 指标 | 累计值 | 当日值 |
|---|---|---|
| 订单数量 | 232,617 单 | 3,064 单 |
| 服务车辆 | 456,237 车次 | 6,127 车次 |
| 注册用户 | 22,099 人 | 新增 111 人 |
这两个数字的关系值得说一句：累计订单 23.26 万单，累计服务车辆 45.62 万车次，比值约 51%。意思是**有一半的车辆进出没有产生计费订单**——短时免费停放占了大头。这不是系统漏单，是路侧停车的真实结构。
这个结构直接影响三件事：一是设备侧要能扛住大量「无订单」的识别事件，不能每条都落库；二是计费引擎要能快速判定免费时段，不能每条都走完整规则链；三是运营分析要把「免费车流」和「付费车流」分开看，否则会误判停车场利用率。
后台除了订单和金额，还有几块是运营方每天要看的：临停与包月的缴费率曲线、实收与应收的差额、巡检任务的执行情况、设备在线率。这些指标决定了坐席人员每天先处理哪一批异常。
很多停车系统的介绍是从功能列表开始的：支持无感支付、支持包月、支持优惠券。这些功能谁都有。真正能区分系统好坏的是「跑起来之后数据长什么样」——单日 3000 单、6000 车次的量级下，免费车流占一半，你的系统还能不能稳住。
现在的状态
4 个停车场目前在持续运营，路侧相机、道闸、智能地锁、巡检车四类设备全部接入统一平台，车位状态、订单流水、设备健康度在一张图上。日常无人值守，异常订单和设备故障集中到远程坐席处理。
这套系统的价值不在功能列表上——市面上停车 SaaS 功能都差不多。真正拉开差距的是三件事：设备适配层能不能快速接新型号、边界状态有没有被显式处理、断网时能不能继续做生意。这三件事在演示里看不出来，但在运营半年后会集中爆发。
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。