在网约车、出租车、旅游包车等移动出行场景中，乘客经常遇到手机电量不足的问题。传统车载充电线虽然可以解决基础用电需求，但通常缺少设备管理、收费、订单追踪和运营结算能力，难以形成可持续的服务体系。

车载共享充电的思路，是在运营车辆内安装带联网和计费能力的充电设备。乘客通过小程序扫描设备二维码，确认价格并完成支付后，平台远程启用充电端口；服务结束后生成订单，并根据实际规则完成结算或退款。

本文结合用户小程序原型，给出一套从用户流程、设备接入到平台运营的落地方案。文中界面为设计原型，设备参数、服务价格和最终功能应以上线版本及实际运营规则为准。

一、项目定位与应用场景

车载共享充电不是简单地在车辆内放置一条充电线，而是一套连接乘客、车辆、车载设备和运营平台的服务系统。

典型应用场景包括：

• 网约车和出租车乘客临时补电；

• 机场、高铁站接送车辆提供增值服务；

• 旅游包车、商务车和长途客运车辆提供途中充电；

• 车队运营方统一管理设备、订单和收益；

• 广告或会员权益与充电服务组合运营。

项目涉及四类参与方：乘客使用小程序完成扫码和支付；司机或车队负责设备保管与车辆运营；平台负责设备、订单、支付和结算；设备供应方负责终端生产、通信和售后维护。

二、用户侧业务流程

完整流程可以设计为：

乘客进入小程序
  -> 微信授权登录
  -> 扫描车内设备二维码
  -> 校验设备与车辆状态
  -> 展示计费说明
  -> 用户支付或预授权
  -> 平台下发启动指令
  -> 设备开启充电端口
  -> 充电倒计时与状态同步
  -> 到时自动结束或用户主动结束
  -> 计算实付与退款
  -> 生成完成订单

1. 首页与扫码入口

小程序首页将“扫码充电”作为主要操作。用户登录后，可以直接扫描车辆内设备上的二维码，不需要先搜索车辆或手动输入设备编号。

二维码不应只保存一个可被随意伪造的数字编号。推荐包含设备公开标识和短期签名参数，平台收到扫码结果后再校验：

• 设备是否已注册并处于启用状态；

• 设备是否已经投放并绑定车辆；

• 当前端口是否空闲；

• 车辆和设备是否在线；

• 二维码签名是否有效、是否过期；

• 当前用户是否存在未支付或进行中的订单。

如果设备尚未投放、已停用或没有绑定车辆，应进入独立提示页，不允许继续支付。原型已经设计了“未投放”状态，这一校验应在创建支付订单之前完成。

2. 充电确认与支付

扫码校验通过后，页面展示车牌号码、设备编号、单次服务时长、收费金额和支付方式。用户在支付前可以确认自己扫描的是当前车辆内的设备。

原型采用单次预付模式，例如预付固定金额后获得一定的服务时长。这种方式流程清晰，但后台仍需把以下配置做成可调整参数：

• 单次价格；

• 标准服务时长；

• 是否按分钟结算；

• 最低消费和封顶金额；

• 提前结束时是否退款；

• 退款金额的计算精度；

• 不同车辆、车队或城市的价格模板；

• 优惠券、会员或免费体验规则。

支付结果必须以支付渠道服务端通知为准，不能只依赖小程序前端返回。平台确认支付成功后才能创建有效充电任务并向设备下发启动指令。

3. 充电进行中

设备成功开启后，首页进入充电状态，突出显示剩余时间。用户可以随时返回订单详情查看支付、设备和充电信息。

倒计时不能只由前端本地计时。平台应保存服务开始时间和计划结束时间，小程序每次进入页面时从服务端重新获取状态。这样可以避免用户切换手机、退出小程序或修改本地时间后出现计费偏差。

运行中至少需要处理以下事件：

• 设备确认端口已开启；

• 用户插入或拔出充电线；

• 设备持续上报输出状态；

• 用户主动结束；

• 服务时间到期；

• 车辆熄火或设备断电；

• 设备离线、过温、过流或短路；

• 平台未收到启动或停止回执。

对于低功率 USB 或 Type-C 车载充电，可以按服务时长计费；如果设备能够可靠采集输出电量，也可以保留电量字段用于运营分析，但不应在未经计量合规评估的情况下直接将其作为收费依据。

4. 订单完成与退款

充电结束后，订单页展示预付金额、实付金额、退款金额、支付方式、计费规则、服务时长、开始时间、结束时间以及设备信息。

如果业务采用预付后按实际时长结算，推荐使用以下流程：

预付成功
  -> 冻结或收取预付金额
  -> 服务结束后计算应收
  -> 应收小于预付：原路退款差额
  -> 应收等于预付：直接完成
  -> 应收大于预付：按规则封顶或生成补缴单

订单状态和退款状态应分别保存。退款处理中，订单可以是“已完成”，但资金状态仍是“退款中”。不要把两者合并为一个状态字段。

三、整体系统架构

落地系统可以分成五层：

用户层
  小程序、司机端、运营后台

接入层
  用户认证、API 网关、支付回调、设备长连接

业务层
  车辆、设备、订单、计费、支付、退款、结算、客服

物联网层
  设备注册、状态上报、指令下发、规则告警、固件升级

数据层
  业务数据库、设备时序数据、日志、对象存储、统计分析

小程序端

用户侧至少包含微信授权登录、扫码、支付确认、充电状态、订单列表、订单详情、个人中心、用户协议、隐私政策和客服反馈。

运营后台

后台负责车队、司机、车辆、设备、投放、计费模板、订单、支付、退款、分账、告警和运营报表。远程启停、人工退款、设备解绑和资金调账属于高风险操作，应要求操作原因、二次确认和审计记录。

设备通信服务

车载设备可以采用 4G、Cat.1 或其他可用网络接入物联网平台。设备与平台之间建议使用 MQTT over TLS 或 HTTPS 长轮询，根据硬件能力选择。每台设备应具有独立身份凭证，不能让同一批设备共用固定密钥。

四、车载设备设计

车载共享充电设备至少需要包含：

• 稳压及电源转换模块；

• USB-A、USB-C 或集成充电线；

• 端口独立通断控制；

• 过压、过流、短路和过温保护；

• 通信模组和设备身份凭证；

• 二维码或设备标签；

• 状态指示灯；

• 可选的线缆插拔检测和输出计量模块。

设备上报的数据可以包括：

设备收到启动指令后，应校验指令编号、有效期和签名，执行后返回明确结果。平台对同一订单重复下发启动指令时，设备需要保证幂等，避免重复计时或多次打开端口。

五、设备投放与车辆绑定

设备从入库到运营建议经过以下步骤：

设备入库
  -> 写入设备身份与密钥
  -> 功能检测
  -> 分配车队或代理商
  -> 安装到车辆
  -> 扫描设备码并录入车牌
  -> 上传安装照片
  -> 在线测试
  -> 审核后正式投放

核心资产关系为：

运营主体 -> 车队 -> 车辆 -> 车载设备 -> 充电端口

同一设备在同一时间只能绑定一辆有效车辆。换车安装时要先结束旧绑定，记录拆卸时间、安装人员、原因和照片，再建立新绑定。历史订单必须保留当时的车牌和绑定快照，不能因为后续换车而改变。

六、订单状态机

建议将业务订单设计为明确的状态机：

待支付
  -> 已支付待启动
  -> 启动中
  -> 充电中
  -> 结束中
  -> 已完成

异常分支：
支付失败 / 启动失败 / 设备离线 / 已取消 / 退款中 / 已退款

关键状态规则如下：

1. 同一设备端口同一时间只能存在一个进行中订单；

2. 支付成功但启动失败时，自动发起全额退款；

3. 平台下发启动指令后必须等待设备回执，不能直接标记为充电中；

4. 结束时间以设备事件和平台接收时间综合判断，并保留两个时间；

5. 设备断网时可以在本地按已授权时长执行，但恢复后必须补传事件；

6. 支付、退款、设备指令和回调均需要幂等处理。

七、核心数据模型

车辆表

vehicle_id、fleet_id、plate_number、vehicle_type、driver_id、
operation_status、bind_device_id、bind_time、unbind_time

设备表

device_id、device_sn、model、imei、firmware_version、secret_id、
online_status、deploy_status、vehicle_id、last_heartbeat、fault_code

充电订单表

order_id、user_id、vehicle_id、device_id、port_no、pricing_rule_id、
prepaid_amount、actual_amount、refund_amount、order_status、
payment_status、start_time、planned_end_time、actual_end_time、end_reason

设备指令表

command_id、device_id、order_id、command_type、request_payload、
send_time、expire_time、response_time、result_code、retry_count

资金流水表

flow_id、order_id、flow_type、payment_channel、channel_flow_no、
amount、status、request_time、success_time、failure_reason

金额建议使用“分”为单位的整数存储。计费规则需要保存版本或快照，避免运营人员修改价格后影响历史订单复算。

八、支付与结算设计

小程序可以使用微信支付完成预付。服务端应实现下单、支付签名、异步通知、主动查询、退款和退款查询，不应将前端支付成功回调作为最终依据。

若项目需要与车队、司机或设备投放方进行收益结算，可以按订单保存分润快照：

订单实收
  - 支付渠道成本
  - 平台服务费
  - 设备及运维成本
  = 可分配收益

具体分配比例由合同和后台规则配置。平台应生成日账单或月账单，支持订单明细核对、差异申诉和结算状态追踪。涉及分账和提现时，需要根据实际业务主体及支付机构规则设计，不能只在数据库中修改余额完成资金划转。

九、异常场景处理

支付成功但设备未启动

平台自动查询设备在线状态并有限次数重试。仍未成功时关闭服务订单并原路退款，同时生成设备异常记录。

设备正在被使用

扫码后直接提示设备繁忙，不创建支付单。用户已进入支付页后才发现占用时，需要再次校验并阻止支付。

设备中途离线

若设备仍在本地供电，可以按授权截止时间继续运行；平台页面显示状态同步中。超过离线阈值后生成告警，恢复连接时补传开始、停止和故障事件。

车辆熄火导致服务中断

设备上报断电事件，平台提前结束订单，按规则计算实付和退款。订单详情中应展示“车辆断电结束”等明确原因。

用户重复支付

创建支付单前检查进行中订单，并以用户、设备和业务请求号设置幂等约束。发现重复支付时，保留一笔有效交易，其余支付自动退款。

二维码被拍照传播

除了校验签名和设备状态，还可以结合短时动态码、车内蓝牙或局部位置校验降低远程扫码风险。不能只依靠静态二维码判断用户就在车内。

十、安全与合规要点

• 用户手机号、OpenID、车牌和支付信息按最小必要原则采集；

• 在小程序中展示服务价格、时长、退款和异常结束规则；

• 支付回调、设备指令和后台接口均校验签名并防止重放；

• 设备密钥按台生成，支持停用和轮换；

• 远程启动、人工退款、调账和设备解绑写入审计日志；

• 设备满足车载电气安全、阻燃、温升和电磁兼容等适用要求；

• 投放前核实车辆运营方授权，避免遮挡驾驶视线或影响车辆安全；

• 上线前根据实际运营地区核实支付、价格展示、隐私和消费者权益要求。

十一、运营后台功能

首期后台建议包含：

• 用户管理：用户、黑名单和异常订单；

• 车队管理：运营主体、车辆、司机和合同；

• 设备管理：入库、投放、绑定、在线状态、故障和固件；

• 订单管理：支付、启动、充电、结束和退款全过程；

• 计费管理：价格、时长、最低消费、封顶和退款规则；

• 财务管理：支付流水、退款、分润、对账和结算；

• 运维管理：告警、工单、维修和设备更换；

• 数据报表：活跃设备、扫码转化、支付成功率、启动成功率、使用时长、客单价、退款率和单车收益。

运营指标要区分“扫码”“支付”“设备启动”和“完成服务”。只有支付成功率而没有设备启动成功率，无法判断真实的服务质量。