不少项目卡在联调，不是程序写不出来，而是开发方拿到的资料只有产品彩页、几张充电桩照片和一句“支持远程控制”。这些还不够。小程序发出的启动指令，通常要经过业务后台，再到设备云平台或充电桩，最后由桩返回启动结果和充电状态。中间任何一段没有协议、账号或测试设备，都会停在那里。
先确认接入路线，这一步会改变整个开发方案
常见做法有两种。
一种是充电桩直接连接新建的运营平台。设备厂家需要提供完整的桩端通信协议，桩里的联网模块也要能修改服务器地址、端口和鉴权参数。这条路线控制权比较完整，适合准备长期运营、多品牌接入或后续还要做会员、分账、运维的项目，但协议适配和设备联调工作更多。
另一种是充电桩继续连接厂家云，小程序后台调用厂家提供的开放接口。已有设备已经批量上线、厂家接口又比较成熟时，这样做通常更快。不过能拿到哪些状态、能不能改计费规则、故障数据保留多久，都受厂家平台能力限制。后续更换设备品牌，也可能需要重新接一套接口。
还有一种情况很容易被忽略：厂家说“支持国标”，不等于小程序后台就能接。GB/T 27930-2023规定的是非车载直流充电机与电动汽车之间的数字通信，解决的是桩和车怎么通信；小程序要控制充电桩，仍然需要桩到运营平台的通信协议，或者厂家云的业务接口。这两层不能混为一谈。
接入路线没有确认之前，页面原型可以讨论，核心功能却不宜直接承诺工期。因为“远程启动”背后可能是厂家一个现成接口，也可能是从二进制报文、长连接和设备状态机开始做，两者工作量不是一个量级。
硬件资料不只是一台充电桩
开发启动前，至少要有一台可反复测试的实机。直流桩、交流桩，多枪设备和单枪设备，如果协议或业务表现不同，最好分别准备。暂时无法提供实机，也应提供厂家认可的协议模拟器和联调环境；只用接口文档推测设备行为，很多异常在上线前发现不了。
随设备一起整理的资料，建议包括：
- 设备品牌、具体型号、交流或直流类型、额定功率、枪口数量、出厂编号和当前固件版本。
- 铭牌、整机外观、屏幕、枪口、急停按钮、二维码粘贴位置的清晰照片，便于确认设备编号与现场操作流程。
- 设备说明书、合格证明、检验或认证资料，以及适用的充电接口、安全和互操作标准版本。2025年8月1日起，
GB 44263-2024和GB 39752-2024已经实施，分别涉及电动汽车传导充电系统和供电设备的安全要求，采购新设备时不能继续只看旧版资料。 - 桩内主控板、计量模块、读卡模块、4G或以太网通信模块的型号与能力说明。涉及计费时，还要确认电能数据来自哪块表、上报精度和结算取值规则。
- SIM卡、APN、ICCID、IMEI、流量套餐、网络运营商，以及设备现场是否有稳定的4G、以太网或Wi-Fi。使用专网卡时，要提前确认能否访问新平台地址。
- 服务器地址和端口的修改方式，是现场屏幕配置、厂家工具配置、串口配置，还是必须由厂家远程下发。
- 设备编号、枪编号、二维码内容三者的对应规则。二维码最好能追到唯一枪口，补打标签、换标或设备迁站后也不能重复。
- 现场配套设备清单。若小程序还要处理道闸、车位锁、摄像机、停车费、储能、光伏或有序充电，这些设备的品牌、控制器和接口也要单独提供。
如果项目还没采购充电桩，设备选型时应把“开放通信协议、允许修改平台地址、提供测试桩或模拟器、支持远程升级”写进采购要求。硬件已经到场以后再谈开放协议，往往最被动。
桩端协议要拿到什么程度，才算能开发
一句“TCP协议”或“MQTT协议”不是接口文档，只说明了连接方式。真正能用于开发的桩端协议，需要把一条消息从哪里开始、每个字节代表什么、设备什么时候发送、平台应该怎样回复都写清楚。
完整资料通常要覆盖这些内容：
- 连接地址、端口、传输方式、长短连接规则、设备鉴权、加密方式、协议版本和兼容范围。
- 报文头、消息类型、长度、字节序、字段编码、校验算法、时间格式和金额、电量的单位。
- 设备注册、登录、心跳、校时、在线与离线判断。
- 设备和枪口状态码，包括空闲、已插枪、启动中、充电中、停止中、故障、预约占用等状态。只给中文说明、不提供原始值，也没法写解析程序。
- 远程启动、远程停止、启动结果、停止原因、实时电压、电流、功率、电量、SOC、充电时长和费用上报。
- 订单开始、过程数据、订单结束、补传机制，以及桩端订单号与平台订单号怎么关联。
- 计费模型，包括尖峰平谷时段、电费与服务费、跨时段结算、费率版本、下发确认和生效时间。
- 告警与故障码，至少说明故障含义、是否影响充电、恢复条件和清除方式。
- 断网续充、离线订单、重新连接、重复报文、命令超时、消息重发和幂等处理。
- 固件查询、远程升级、升级进度与失败回退；如果设备不支持，也应明确写出。
- 每种报文的真实示例，最好同时提供一份正常充电的完整通信记录，能从插枪一直看到结算结束。
多品牌接入时，不要让小程序分别理解每家设备状态。更稳妥的做法是先在平台侧把各厂家协议转换成统一的设备、枪口、告警和订单模型。否则同样叫“充电中”，一家上报设备状态，一家上报枪状态，业务层很快就会被品牌差异拖住。
厂家云接口也要问到回调和异常
如果走厂家云接口，需要的不只是一个接口地址和账号。至少应取得正式的开放平台文档、测试账号、测试站点、接口白名单配置方法和技术支持边界。
鉴权方式要写明白，是固定令牌、签名、OAuth，还是证书；令牌多久过期，服务器时间偏差允许多少。查询接口应包含站点、设备、枪口、费率、实时状态和历史订单。控制接口则要覆盖启动、停止、订单查询、退款后的业务处理，以及命令受理和最终执行结果的区别。
回调资料更关键。设备状态变化、启动结果、充电过程、订单结束和故障告警由谁推送，失败后会不会重试，重复回调怎样识别，回调签名怎么验，都应在文档里写清楚。没有这些约定，测试时看着能充电，网络一抖就可能出现小程序显示失败、设备却已经启动，或者同一笔订单入账两次。
小程序和支付资料，最好与设备资料同时准备
微信侧需要企业主体的小程序账号、AppID、管理员与开发成员权限。后端采用自建服务器时，还要准备已备案域名和有效的HTTPS证书，并在小程序后台配置通信域名。微信开放文档明确要求，小程序只能与已配置的域名通信，普通请求使用HTTPS，WebSocket使用WSS，域名不能直接写公网IP或localhost。
涉及手机号、位置信息等个人信息时，应先列清楚业务为什么需要，再配置《小程序用户隐私保护指引》和对应授权流程。不是页面上放一段隐私政策就结束了；未声明所处理的信息，相应接口或组件可能无法调用。
微信支付要准备已开通对应产品的商户号，并确认商户号与小程序AppID已经绑定。开发阶段还需要APIv3密钥、商户私钥、证书或微信支付公钥配置，以及支付和退款回调地址。密钥材料不要放进需求文档和聊天记录，应由授权人员通过安全方式交接。订单金额、充电预付、余额退款、原路退款、发票和分账是否需要，也应在开发前定下来。官方小程序支付接口要求下单时提供相互绑定的appid和mchid，这类账号关系没有准备好，支付联调无法完成。
地图导航、短信、电子发票、停车缴费、会员体系、企业车队、客服工单如果在首期范围内，各自还需要平台账号、接口文档、测试额度、回调地址和数据字段。这里最怕一句“后面再接”却先把业务流程写死。以后接停车费时，订单可能要等出场结果才能结算；接企业车队时，付款人又未必是实际充电人。
开发前还要拿到一份能跑通的测试条件
资料齐全不等于能够联调。红数科技在项目启动前会把测试条件单独核一遍：测试桩能否长期在线，是否允许反复启停，有没有可实际充电的车辆或负载，谁能在现场插枪、复位和处理急停，设备厂家在什么时间配合看日志。直流桩还要覆盖车辆握手和BMS通信，单纯让平台收到心跳，离真实充电还很远。
首轮验收不要只测“扫码后能启动”。至少应走完正常启动和停止、用户主动停止、余额不足、拔枪或车辆停止、急停、设备故障、桩端拒绝启动、网络中断、断网恢复、订单补传、重复回调、支付成功回调延迟和退款。每个场景都要对照三处结果：设备实际动作、小程序显示、后台订单和金额。三处一致，才叫闭环。
一份可以直接交给开发公司的准备清单
在询价或排期前，项目方可以把下面这些内容装进同一个资料包：
- 项目范围：首期做哪些站点、多少台桩、哪些设备品牌，面向社会车辆、园区员工还是企业车队。
- 接入方式：设备直连新平台，还是通过厂家云；若多品牌并存，分别写清每个品牌的路线。
- 硬件资料：型号表、说明书、固件版本、通信模块、联网参数、编号与二维码规则、现场照片。
- 接口资料：桩端协议或厂家云API、完整字段说明、状态码、故障码、计费规则、签名方法、回调和重试规则、真实报文示例。
- 平台账号：小程序AppID、微信支付商户号、已备案域名、服务器与证书安排，以及地图、短信、发票、停车等第三方账号。
- 测试条件：实机或模拟器、测试车辆或负载、现场配合人、厂家联调人、测试时段和日志获取方式。
- 验收口径：设备、枪口、订单、电量、金额以哪一端为准，异常订单由系统自动处理还是转人工，数据保留多久。
有些资料确实要等开发中再细化，但设备能不能接、谁提供协议、如何测试，不能等。把这三件事确认下来，开发公司才能给出接近真实情况的方案和工期；否则再完整的功能清单，也只是建立在“设备应该能配合”的假设上。
