企业官网建设流程全解析

简介：这是一套面向智慧交通领域开发者与高校计算机专业学生的无人值守停车与充电一体化系统完整源码包，聚焦停车场数字化升级痛点，提供小程序端、Java后端及岗亭终端三端协同解决方案。资源共2000个文件，含1753个Java业务逻辑与SDK调用类（如HCNetSDK、DeviceMessage等）、158个MyBatis映射XML、51个Markdown说明文档及配套配置文件，压缩包大小58.66MB，技术栈覆盖SpringBoot+MySQL 5.7+Tomcat9+Uniapp+jQueryEasyUI+Bootstrap，适配中高级全栈开发学习与二次开发需求。已有64人下载学习，可直接部署运行，快速掌握车辆进出管理、充电订单调度、月卡与余额体系、收费规则动态配置等核心模块实现逻辑，并通过说明文档与结构化代码目录高效理解系统分层设计与物联网设备对接细节。 停车和充电，在很多人的认知里是两个独立的系统：停车归停车，充电归充电，最多做个接口对接。但真正把一个无人值守的场站运营起来之后，你会发现这套思路根本走不通。用户开车进场、找车位、插枪充电、充满离场，整个过程如果还要在两套毫无关联的系统里来回切换，体验感会很差，运营方也会在账单和异常处理上疲于奔命。

我做的这套“无人值守停车、充电系统”，是一套完整的三端方案，包含小程序端源码、后端源码、岗亭端源码。简单说就是：车主用微信小程序完成查车位、充电、缴费、开发票；后端负责计费、订单、支付、设备状态这些核心中枢逻辑；岗亭端做异常兜底和远程值守，处理那些机器搞不定的边界情况。这个项目适合正在做智慧停车平台、充电运营平台，或者想从0到1搭建一套无人值守场站方案的技术团队参考，也适合想进入这个行业、先搞懂业务闭环的开发者阅读。

下面我会从业务模型、技术选型、出入场链路、充电计费、资金对账、岗亭端设计、部署排坑这几个维度，把这个系统从头到尾拆开讲清楚。

1. 做好无人值守系统前，先想明白的业务闭环

很多人拿到这类源码，第一件事就打开代码目录，去找车辆识别、道闸控制的接口。这个顺序其实反了。一个无人值守停车充电系统能不能落地，核心不在于代码写得有多花哨，而在于你有没有把业务闭环想清楚。代码只是把业务逻辑固化下来而已，业务模型错了，代码写得再好也是空中楼阁。

1.1 车主视角的一小时：从找位到离场发生了什么

我们用一个最典型的场景来推演整个流程。假设一个车主开车进了一个商业综合体，地下一层是停车场，其中靠墙一侧装了20个交流充电桩。

车主进场之前，在小程序里可以看到这个场站还剩多少车位、哪些充电桩空闲、当前电价是多少。到了场站入口，车牌识别相机抓拍车牌，道闸自动抬起，入场记录生成。车主停好车，插上充电枪，在小程序里扫码桩上的二维码，看到当前电价后确认启动充电。这个时候，计费引擎要做两件事：记录充电订单的开始时间，同时联动停车计费逻辑，给这辆车打上“充电中”标记。车主上楼逛商场，期间通过小程序实时看到充电功率、已充电量、预估金额。充完电后，小程序推送通知。车主下来拔枪开走，到出口时相机再次识别车牌，系统把停车费、充电订单合并计算：充电时长内的停车费按免费处理，超出的部分正常计费。用户在小程序里一键支付，道闸抬起，离场完成。

整个过程里，用户只主动做了“插枪、扫码、确认启动充电、支付”这四件事，其他全部由系统自动完成。这就是无人值守系统的核心体验目标：把用户的主动操作压缩到最少，把系统的自动化覆盖到每个环节。

1.2 运营方真正需要的不是“自动化”，而是“少纠纷”

很多做技术的人搞无人值守系统，容易陷入一个执念：我要让所有流程都自动化，所有操作都机器完成。但实际上，运营方最关心的根本不是自动化率有多高，而是“每天能不能少接几个投诉电话、少处理几笔纠纷退款”。

举一个实际会遇到的情况：有辆车入场时车牌识别相机把“A”识别成“4”，出场时又识别对了，系统就认为这是两辆不同的车。如果这时候车位级管理逻辑不够严谨，可能出现这辆车入场记录还在，但没有出场记录，停车费越积越多的状态。还有一些更隐蔽的问题，比如同一个车牌短时间内多次进出，是否存在跟车逃费；充电桩启动瞬间推送的电量数据是不是准确；用户充完电忘了拔枪就开到出口，费用到底怎么算。

这些场景，每一个都是潜在的客诉。所以我在设计这个系统时，把“纠纷可追溯”作为第一原则。所有计费过程必须有明细记录，所有减免策略必须有日志留痕，所有异常事件必须在岗亭端生成可处理的工单。自动化是为了减少人工操作，但可追溯、可介入、可解释，才是无人值守系统能长期稳定运营的真正基础。

1.3 停车与充电为什么要做同一套账

如果停车和充电是两套独立系统，就会出现一个很常见的问题：停车系统只记录车辆进出时间，充电系统只记录充电订单，两套账各自独立，月底运营方根本对不上。

比如“充电减免停车费”这个业务场景，充电订单显示这辆车充了20度电、减免了2小时停车费，但停车系统里这辆车入场出场记录都正常，就是费用没减成，因为两边没有联动。或者反过来，停车费已经减免了，但充电订单在退款时又把这部分费用原路退给了用户，等于运营方双倍损失。

这套系统的账务设计核心是“一辆车一个账单”。不管用户在这个场站里做了几次充电、停了多久车，出场时生成唯一结算单，停车费和充电费在同一个账单体系内汇总、优惠、支付、退款。代码层面，后端用一个账单主表关联停车订单、充电订单、减免记录、支付流水这几个子表，任何一步操作都有据可查。这套设计思路，也是整个三端源码里最值得仔细研究的地方。

2. 三端源码怎么分工，技术栈为什么这样选

项目标题里明确写了包含小程序源码、后端源码、岗亭端源码，这三个部分不是各自孤立的三个项目，而是一个完整的闭环。每一端要解决的问题不同，所以技术选型和代码组织方式也完全不同。

2.1 小程序端定位：车主所有操作的入口

小程序端是用户和整个系统交互的唯一入口，所以它的功能边界要以“用户场景”来划分，而不是以“后台功能”来划分。

我建议小程序端包含以下核心模块：查找场站、查看剩余车位和空闲充电桩、实时电价展示、一键导航、账号登录和手机号绑定、车辆绑定和管理、充电订单启动和停止、充电状态实时展示、停车缴费、发票申请、月卡购买、消息通知。这些模块按产品功能划分，和后台的数据模型一一对应。

技术选型上，我推荐使用原生微信小程序开发或者uni-app。如果项目只做微信生态，原生小程序就行，包体积小、启动快、兼容性好；如果团队考虑后续做App或者支付宝小程序，uni-app会更合适。不过我强调一点：无论选什么框架，小程序端尽量不要放核心业务逻辑，它只负责展示和提交操作。计费、优惠计算、订单状态判断这类逻辑必须放在后端，理由很简单——小程序的代码跑在用户手机里，一旦核心逻辑暴露到客户端，不仅容易被逆向分析，版本更新也不可控制。前端所有数据都必须以服务端下发的状态为准，这一点在源码设计时是作为硬性约束存在的。

2.2 后端定位：计费、订单、支付、设备状态的中枢

后端是整个系统的核心，它既要处理业务请求，又要对接硬件设备，还要做运营管理。我按职责把后端拆成几大模块。

用户模块负责账号体系、微信登录、手机号绑定、车辆信息管理。停车模块负责入场、出场、车位管理、道闸控制。充电模块负责充电桩对接、远程启停、状态采集、充电订单管理。计费模块是整个系统的核心，负责停车费、电费、服务费、减免规则的统一计算。支付模块负责微信支付/支付宝支付的统一下单、回调、退款、对账。设备模块负责车牌识别相机、道闸、充电桩、地锁、地感线圈等硬件设备的接入和状态监控。消息模块负责小程序订阅消息推送、短信通知。运营模块负责管理后台接口、报表统计、发票管理。

这里的技术选型，我最终选了Spring Boot作为后端主框架，搭配MySQL存业务数据、Redis做缓存和分布式锁、RabbitMQ做事件消息队列。为什么不选Python或者Node.js？不是因为它们做不了，而是在这个业务场景里，Java生态对支付对接、多线程并发、分布式事务、定时任务这些能力的支持是最成熟的。停车充电业务有大量的并发场景，比如高峰时段多辆车同时进出场、多个用户同时启动充电，Spring Boot的线程模型和事务管理能力能帮我们省掉很多底层的坑。

2.3 岗亭端定位：不是人肉客服，是异常兜底

岗亭端这个名字听起来有点传统，很多人会问：都无人值守了，还要岗亭做什么？这是对岗亭端最大的误解。岗亭端在无人值守系统里的角色，不是收费员坐班，而是异常事件处理中心和远程值守工作台。

岗亭端的核心功能包括：实时监控场站内所有设备状态，包括相机、道闸、充电桩、地锁的在线率和运行状态；处理识别失败、支付失败、设备离线等异常事件，支持远程手动抬杆、手动录入车牌、人工创建订单；查看所有订单明细和计费日志，处理用户投诉时的退款和补单；多场站集中管理，一个运营人员可以同时盯多个场站的大屏。

技术形态上，我用的是B/S架构，运营人员打开浏览器就能用，不需要装任何客户端。但在设计上有两个点必须留意：一是岗亭端要能处理公网断网的情况，所以本地会部署一个轻量级的本地服务程序，负责相机回调、道闸控制的本地缓存和离线兜底；二是岗亭端的事件工单要有独立的持久化存储，不能因为系统重启就丢失。

3. 车辆出入场与车位识别：最容易出问题的链路

车辆出入场是每个场站最高频的操作，也是无人值守系统里最容易出问题的链路。识别失败、重复入场、跟车逃费、无牌车处理，这些问题只要出现一个，现场体验就崩了。

3.1 车牌识别与道闸联动的基本流程

一次完整的入场流程是这样的：车辆驶入车道，车牌识别相机抓拍并识别车牌，把识别结果以HTTP回调的方式推送给后端；后端收到回调后，先校验这个车牌是否在系统内有有效记录，然后判断车辆类型：月卡车直接放行，临时车落杆前自动生成入场记录；白名单车辆（比如内部车辆、警车消防车）直接放行；如果系统判断有异常（比如这个车牌还没有出场记录，重复入场），则不下发开闸指令，而是把事件推送到岗亭端，由人工介入处理。

道闸联动这个环节，很多人会忽略一个细节：开闸指令的下发时机。如果等到相机完全识别完、后端处理完所有逻辑再开闸，车辆早就开到道闸跟前了，体验会很差。我建议在相机识别回调到达后的几百毫秒内就完成校验并下发开闸指令，同时利用地感线圈或雷达做防砸保护。开闸指令和设备IO的关系也很关键，代码里一定要明确道闸控制器的“常开/常闭”逻辑，避免出现“给开闸信号反而关闸”的乌龙。

3.2 免费识别方案的边界与商业相机的必要

车牌识别是整个系统的起点，识别率直接决定无人值守的可行性。对于想低成本起步的团队，可能会考虑用树莓派加开源OCR方案，比如PaddleOCR或者OpenALPR。这种方案在小规模测试环境下是可行的，但是要把它放到生产环境，我劝你慎重。

我实际测试过，开源的OCR模型在标准光照、清晰车牌情况下的识别率能到95%以上，但一旦遇到夜间强光、雨天水渍、车牌污损、新能源绿牌、挂车黄牌这些情况，准确率会断崖式下降。商业车牌识别相机（比如臻识、海康、大华这些品牌）在识别率上能做到99%以上，而且内置了补光灯、偏振镜，对逆光、夜间场景做了专门优化，识别延迟也低。所以我给出的判断是：学习和小规模试用，开源方案完全够用；但如果你想做一个正经运营的无人值守场站，直接上商业车牌识别相机，虽然单台设备贵一些，但省下来的客诉成本和人工介入成本会远远超过设备差价。

3.3 二次入场、无牌车、识别错误这几个坑

这几个问题是我在实际项目中踩过最多次的坑，源码里每一处对应处理逻辑都值得认真看。

第一个是重复入场。有些车辆出场时识别失败，系统没有生成出场记录，车又开回来了，这时候如果直接放行，就会出现一个车牌对应两条未完结入场记录的情况。我的处理方式是在后端维护一个车辆在场状态的唯一约束：同一车牌在同一场站下，最多只能有一条未出场的入场记录；如果发现重复入场，系统不下发开闸指令，而是推送事件到岗亭端，由值守人员核验后手动处理。

第二个是无牌车和污损车牌。这种车没法靠相机识别，常见做法是提供一个入场二维码，车主扫码后生成一个临时进场凭证，绑定一个临时车牌号（比如“无牌-时间戳”）。出场时由岗亭端人工核验，确认后放行。这个功能必须预留，否则没有车牌的车辆进不来也出不去，现场会直接堵死。

第三个是识别错误造成的计费纠纷。比如入场识别成A车，出场识别成B车，系统里就会多出一条A车的未离场记录，同时B车突然多出一段没有入场记录的停车时长。为了避免这类纠纷，我在出场确认环节加了一个人工确认操作：当相机识别结果和入场记录匹配度不够高时（比如置信度低于某个阈值，或者车牌省份缩写对不上），系统会默认推送到岗亭端，由人工确认实际车牌后再放行。当然，如果完全依赖人工，无人值守又失去意义，所以这个确认操作只在低置信度场景下触发，正常识别的车辆还是全自动放行。

4. 充电桩对接与计费策略：电和停车费怎么算明白

充电业务是整个系统的增值部分，也是运营方真正的利润来源。但充电计费比停车计费要复杂得多，因为它牵扯到电费实时浮动、服务费规则、充电时长减免、占位费管理这些维度。

4.1 充电启动与停止的交互流程

交流桩和直流桩的协议不同，但业务交互流程是一致的。我在系统里对接充电桩时，优先用的是OCPP协议，因为OCPP对远程启停、状态上报、交易记录这些核心能力定义得比较完善。如果充电桩厂商只提供私有协议（Modbus TCP或者MQTT），也可以对接，但需要在设备接入层做一层协议适配器，把不同厂商协议的差异屏蔽在内部。

一次完整的充电流程是这样的：用户在小程序扫码，小程序向后端发起“查询桩状态”请求；后端从设备模块读实时状态，确认充电桩空闲后，返回当前电价和预计费用等信息；用户确认启动，后端向充电桩下发远程启动指令；充电桩返回启动成功，后端生成本次充电订单，状态为“充电中”。

充电过程中，后端通过协议周期性采集充电功率、累计电量、电压电流这些数据，并通过WebSocket或者订阅消息推送到小程序端展示。停止充电有三种触发方式：用户手动停止、SOC充满自动停止、账户余额不足停止。无论哪种方式停止，后端都要等待充电桩上报最终交易记录（包含最终累计电量），然后生成最终金额。

4.2 电费+服务费的拆分逻辑

充电费用由电费和服务费两部分组成。电费是成本价，一般按照当地峰谷平电价实时浮动；服务费是运营方的毛利，通常是固定价格。比如某地当前商业电价为峰段1.2元/度，你的服务费定价0.4元/度，那么用户实际支付就是1.6元/度。

在源码设计里，电费不能简单用一个固定值，而是要支持电价策略。我在系统里设计了一个电价表，按场站、按时间区间配置不同时段的电价。同时，服务费也要可以按场站、按桩类型（快充/慢充）配置。计费引擎在生成充电订单时，会根据“充电启动时间”和“充电结束时间”判断落在哪些电价区间，然后分段计算电费总额。如果跨了多个电价区间，要按区间分别计算后累加，不能直接用结束时刻的电价算整单。

4.3 充电减免停车费与超时占位费设计

停车和充电的联动，主要落在两个策略上：充电减免停车费和超时占位费。

充电减免停车费的逻辑，是无人值守停车充电系统的核心卖点。我建议按“免费时长”来设计：比如充电满5分钟以上的车辆，停车费减免2小时，超出部分按正常费率计算。这个减免策略放在计费引擎的“费用减免规则链”里执行，顺序是：先算基础停车费，然后应用充电减免，再应用优惠券和月卡减免，最后计算实付金额。每一步都要留下减免明细记录，方便日后对账和客诉排查。

超时占位费解决的是“充满不走”的问题。如果一辆车充满电后长时间占用充电车位，运营方的翻台率就上不来。策略是：充电订单结束后，给用户一个宽限期（比如30分钟），超过宽限期开始按分钟计收占位费，费率可以按正常停车费的倍数来设。这个功能在实际运营中非常重要，很多只做停车系统或只做充电系统的产品都忽略了这个需求，导致充电车位被长期占用，运营效率上不去。

5. 支付流程与资金对账：无人值守的信任基础

无人值守系统最敏感的问题就是钱。用户都不愿意多付一分钱，运营方也不愿意少收一分钱。所以支付流程和资金对账，是这个系统设计中最需要细致处理的部分。

5.1 一次完整的出场扣费要经过几个环节

出场的支付流程比入场复杂得多。我设计的是“先结算、后支付、再抬杆”的流程链。

车辆到出口，相机识别车牌，后端根据入场记录查这个车是否有未完结的账单。账单引擎开始结算：计算停车时长，计算停车费，关联这个车牌在本次入场期间的所有充电订单，应用充电减免策略，生成最终应支付金额。如果应支付金额为0（比如月卡车，或者减免后正好抵消），直接放行。如果金额大于0，后端向小程序推送一条待支付消息。用户打开小程序点击支付，拉起微信支付。支付成功后微信回调到后端，后端更新账单状态为“已支付”，然后向道闸下发开闸指令。

有些系统为了节省出场时间，采用“先抬杆、后扣费”的信用模式，开通了微信免密支付的用户，车牌识别后直接抬杆，后端在后台静默发起扣款。这个体验确实好，但对支付异常的处理要求非常高。如果扣款失败，车已经走了，之后只能通过短信、小程序消息追缴。所以我建议把这个功能作为一个可配置项，默认关闭，只在信用体系相对完善的场景下开启。

5.2 回调幂等、退款和异常金额处理

支付回调是整个支付链路里最容易出问题的环节。微信支付回调可能会因为网络原因重复推送，如果后端没有做幂等处理，同一个订单被更新两次支付状态，就会出现严重的数据问题。我的做法是在后端用“订单状态+Redis分布式锁”双保险：先查订单当前状态，如果已经是“已支付”，直接返回成功，不再执行后续逻辑；同时加分布式锁，防止并发回调同时进入业务代码。

退款场景也比想象中多：用户重复支付、充电中途停止后剩余服务费需要退、多扣费需要纠正、客人投诉后运营方主动退款。每一次退款都要生成独立的退款单，关联到原支付单，并在退款成功后更新账单和充电订单状态。所有退款操作都要记录操作人（如果是在岗亭端由运营人员发起的退款），便于后续审计。

金额计算还有一个大坑：浮点精度。停车费、电费、服务费、优惠减免，这些字段如果直接用浮点运算，会在某些场景下出现0.1+0.2不等于0.3的问题。我在整套源码里把金额相关的计算全部改为以“分”为单位的整数运算，只在最后展示时转成元，彻底规避了浮点误差。

5.3 日结与对账报表怎么设计

每日凌晨，系统会跑一个日结对账任务。对账的逻辑是把三份数据做比对：平台账单明细、微信支付/支付宝支付账单明细、充电桩上报的交易记录。任何一个订单在这三份数据中不一致，都会生成一条差异记录，推送到岗亭端和运营后台。

具体来说，对账分几个层级：交易笔数和金额对平；逐单核对平台订单状态和支付回调是否一致；核对充电订单的最终电量和计费金额是否和充电桩上报的交易记录一致；核对停车订单的出入场记录和时间是否连续完整。如果有不一致，系统会标记异常，运营人员可以在岗亭端看到差异详情并手动处理。这个日结功能我强烈建议一期就做进去，因为它才是无人值守系统长期稳定运营的保障，没有对账机制，资金漏洞根本发现不了。

6. 岗亭端源码的真正价值：远程值守与离线兜底

岗亭端在整个三端源码里看起来功能最少，但恰恰是最能体现“无人值守不是无人管理”这个概念的部分。它承担的是系统的最后一道防线，任何自动化流程处理不了的异常，最终都会落到岗亭端。

6.1 岗亭端的“事件队列”设计

我在岗亭端里设计了一个全局事件队列，所有异常事件都按统一格式进入这个队列。事件类型包括：设备离线（相机、道闸、充电桩）、识别失败、重复入场、支付超时、车辆滞留超时、充电桩故障、紧急呼叫（用户在充电桩上按下SOS按钮）、无牌车进场等。

每类事件都有独立的优先级和超时提醒机制。比如“设备离线”这类事件优先级最高，如果摄像头离线超过5分钟，岗亭端大屏会红色告警并播放提示音；而“无牌车进场”这类事件只会在待处理列表里显示，不需要立刻告警。事件工单支持指派和流转，处理完成必须填写处理结果，所有操作都有操作日志。这套事件队列机制，让一个运营人员可以同时管理10个以上的场站，而不需要在每个场站安排驻场人员。

6.2 离线场景下如何保证不丢单不逃费

公网断网是无人值守系统躲不开的场景。如果整个系统完全依赖云端后端，断网就意味着所有车辆进出不了场，充电桩也无法启动，整个场站直接瘫痪。所以我建议在岗亭端做一层本地服务，作用是离线兜底。

本地服务会缓存场站的月卡车白名单和收费规则，断网时，车辆出入场流程由本地服务接管，正常开闸、正常生成入场记录。充电桩的启动和停止也由本地服务代理，离线期间产生的订单先保存在本地，等网络恢复后，再把离线期间的数据补传到云端。同时在云端后端做数据校验和幂等处理，确保补传的数据不会和云端已有数据冲突。这套架构是无人值守系统在弱网环境下能正常运营的关键，强烈建议在源码设计阶段就考虑进去，而不是等线上出问题再补救。

6.3 远程值守与多场站管理

岗亭端的B/S管理界面，本质上是一个多场站监控台。场站列表、设备状态、实时事件流、今日营收、充电量、停车量，这些指标一屏展示。运营人员点击任意场站，可以看到该场站的实时画面（需要接入摄像头流）、当前在场车辆数、充电桩占用情况、异常事件列表。

从商业模式上看，这套远程值守能力决定了运营团队的边际成本。一个运营人员盯一个场站，人力成本高，无人值守就失去了意义；但如果一个运营人员能通过岗亭端同时盯多个场站，人力成本就大幅摊薄，这才是无人值守商业模式能跑通的根本。所以岗亭端在设计之初就是按多场站运营平台来做的，而不是单场站管理工具。

7. 从源码到上线：部署步骤与排坑清单

最后说说源码怎么落地上线。很多团队拿到源码第一步就想把所有功能都跑起来，结果被环境问题、依赖问题卡住。我建议按照下面这个顺序一步步来，能少踩很多坑。

7.1 最低成本跑通整个系统的部署结构

最低成本的部署结构是这样：一台4核8G的Linux云服务器，装好Docker和Docker Compose；用Docker Compose一键启动MySQL、Redis、RabbitMQ，以及Java后端服务和Nginx；前端小程序用微信开发者工具直接导入小程序源码，把请求地址指向云服务器的HTTPS域名；岗亭端在本地的Windows电脑上运行，本地服务负责连接道闸控制器和车牌相机。

对应的部署顺序是：第一步注册小程序账号，完成微信认证，配置服务器域名；第二步部署后端，创建MySQL数据库并执行初始化SQL脚本，启动Redis和RabbitMQ；第三步启动后端服务，用Postman或者平台自带的管理后台接口验证登录、场站管理、设备管理这些基础功能；第四步用测试车牌数据模拟出入场流程，确认道闸联动逻辑正常；第五步接入真实充电桩，跑通远程启停和状态上报；第六步开通微信支付，配置支付回调地址；最后在岗亭端部署本地服务，连接真实设备，完成整链路联调。

7.2 我踩过的几个坑

第一，道闸控制器和相机的IO接线逻辑一定要在代码里显式配置。不同品牌的道闸控制器，开闸信号可能是常开型，也可能是常闭型，如果默认值设反了，就会出现“程序里下发了开闸指令，道闸反而关得更紧”的情况。我因为这个差点把一台道闸电机烧掉，后来在设备配置表里加了一个“IO电平极性”字段，每个场站单独配置，问题才彻底解决。

第二，充电桩上报的电量数据在启动瞬间经常是0。如果直接把这条数据入库，充电订单的首度电费就会出现异常。我后来在设备接入层加了一个数据过滤逻辑：启动后前几秒的电量上报不直接入库，只作为状态展示，等数据稳定后再开始计量。

第三，微信小程序的手机号授权接口已经变更了，老式的“wx.getPhoneNumber”已经不能直接获取手机号，现在要通过手机号快速验证组件来获取。如果团队以前没做过微信小程序，这块很容易踩坑，而且这个接口的申请和审核还需要一定时间，建议提前规划。

第四，金额字段永远用整数类型存储，单位是分。这个我在前面提到过，但还是要再强调，停车充电业务涉及大量金额计算和减免，浮点运算的误差在单个订单上可能只差一分钱，但到了月度汇总和对账阶段，就会变成对不上的大账。

7.3 后续可扩展的方向

这套系统的架构，为后续扩展留了足够的空间。比如对接ETC无感支付，在出口设备加一个ETC读头，识别到ETC标签后直接扣款抬杆，可以进一步提升出场效率。又比如对接政府停车平台，把场站余位、订单数据实时上报，满足市政统一监管的要求。再比如充电桩聚合，目前系统已经抽象了设备协议适配层，后续接入更多品牌的充电桩只需要新写对应的适配器，不需要改动核心业务逻辑。

另外，如果运营方有会员体系需求，可以在计费引擎的减免规则链上扩展“会员折扣”和“积分抵现”，整个减免规则链已经支持了规则的叠加和优先级控制，加新规则不需要改核心代码。

最后再分享一个我个人的体会。做无人值守停车充电系统，真正难的不是代码本身，而是把“支付”“计费”“异常处理”这三件事做对。很多项目技术上看着很漂亮，一上线就死在账单对不上、客户投诉处理不过来这些细节上。如果你也是一边做系统一边做运营，建议先用真实场站的录像和账单把流程完整跑几遍，再回到代码上调整，你会发现设计思路会完全不一样。

本文还有配套的精品资源，点击获取